Web 应用程序 - 合并还是分开？答案

【问题标题】：Web applications - combine or separate?Web 应用程序 - 合并还是分开？
【发布时间】：2011-01-11 04:33:22
【问题描述】：

我正在为我们公司创建一个大型外联网网站，其中包含一组子应用程序。我对解决方案和项目的正确设置感到有些困惑。

我有一个 Web 应用程序，我们称之为 Portal。它包含身份验证/授权类、母版页、导航/url 路由类和主题定义。它还将包含一些基本概述，供我们的客户快速了解他们的项目状态。

来年，我们将开发更多应用程序并将其与门户网站集成。将其视为称为功能 A、B 和 C 的详细概述和工具。多年来，我们将改进这些应用程序并发布新版本。这些 Web 应用程序应该无缝地适应门户网站的导航。我希望他们重用母版页和主题。

设置此解决方案的正确方法是什么？
如何将应用程序捆绑在一起，重复使用母版页并保持可维护性？
如何以正确的方式共享某些 Web 控件 (ASCX)？
我们正在使用 TFS，也许有任何分支/合并的想法？

编辑：
我想在 ASP.Net WebForms 中创建它，我们在该领域拥有最多的经验。但基本上我们可以使用任何东西，我们将网络服务器置于我们自己的控制之下（只要它是面向微软的，而不是切换到 php 或类似的东西:)）

【问题讨论】：

您想使用任何特定的框架吗？ Webforms，asp.net mvc，还有什么？

标签： asp.net web-applications master-pages extranet

【解决方案1】：

我会考虑让您的系统尽可能松散耦合。随着/当您添加更多应用程序时，您的网站将变得越来越不可靠（因为没有任何组件会在 100% 的时间内运行，将这些组合起来会降低您的整体可靠性）。所以你应该构建你的系统来满足非主要服务的需求（我相信亚马逊主页，例如，有 100 种服务对其做出贡献，因此它是为了容错而构建的）

您的服务之间的 API 应尽可能保持稳定，以便在不破坏耦合的情况下更改实现。您还应该研究在 Web 级别对此进行的自动化测试（可能是 Selenium 或类似的？），因为测试单个服务将几乎无法覆盖整体行为。

【讨论】：

【解决方案2】：

正如 Brian 所说，在公开 API 时，您应该尽可能多地承诺它，这意味着它应该在初始发布后尽可能少地改变。然而，要使某些东西变得稳定需要预先付出大量努力，因此如果您还没有准备好提交 API，您应该尽可能地将其内部化，因此您可能希望将它们组合起来而不是分离它们。

但是，我不会根据 5 段描述来推荐适合您的应用程序的架构。你需要做的是权衡拥有几个大项目与拥有一堆松散耦合的小项目的利弊。我的意思是，如果你坚持计划，你提前做的计划越多，你就越容易做到。

因此，与 Brians 的回答相反，我不建议您让整个系统“尽可能松耦合”，只要让它尽可能松耦合即可。 ;) 如果你滥用它，松散耦合的代码会造成与紧密耦合的代码一样多的麻烦。

参见：
1.What is better, many small assemblies, or one big assembly?
2.Specific down-sides to many-‘small’-assemblies?

最后，只有您自己知道自己想在每一项“...能力”、可维护性、可扩展性、可靠性等方面投入多少精力。因此，请明确您的优先事项和目标，并相应地进行计划。

关于分支策略，您可以阅读TFS Branching Guideline 2.0，其中很好地介绍了从基本到高级的各种分支策略。即使您不使用 TFS，这也是一个很好的阅读指南（我目前使用 SVN）。由于我目前在有 1-4 名开发人员的小团队中工作，因此我倾向于使用介于基本和标准之间的策略。不是我向你推荐这个，而是最适合我们团队的方法。

至于在项目之间共享代码。在 SVN 中，我们可以使用“externals”，这意味着共享文件将出现在多个文件夹中，因此当您更改一个副本并将更改提交到 svn 时，所有其他副本将在下一次 svn 更新时更新。但是，我不记得 TFS 是否有类似的东西。

注意：注意 SVN 中的外部...它们可能会导致...问题。 ;)

我的建议是尽量避免共享 aspx、ascx 和母版页。它通常带来的伤害远大于帮助。而是尝试使用继承或其他替代方法来实现您的目标。

ASP.NET MVC 2.0 有一个称为“区域”的概念，您可以在其中构建与其余部分隔离的应用程序的子部分。据我所知，这些区域可以在与“主”应用程序不同的项目中维护。这听起来很像您的要求，所以也许您应该调查一下。

希望这是有道理的。 ;)

【讨论】：

【解决方案3】：

您可能会发现实现自定义VirtualPathProvider 很有用。在我的上一个项目中，我们有多个 ASP.NET 站点需要共享主题文件（母版页、用户控件、图像、样式表），因此我创建了一个 VirtualPathProvider，它允许我们将虚拟文件夹（例如 /Themes）映射到任何物理文件夹硬盘驱动器上的文件夹（例如 C:\Shared\SiteThemes）。

这不是微不足道的，但没有花费太长时间，也没有造成任何问题。顺便说一句，它被证明是克服 WiX 中最大组件限制的好方法...请注意，您不能预编译使用 VirtualPathProvider 的站点。

【讨论】：

【解决方案4】：

What is the proper way to setup this solution?

正确的方法...有很多。我见过很多应用程序，以及很多不同设置（其中很多我认为是“合适的”）。您真正需要的是针对您的情况找到最佳方法。

因为您正在构建一个门户，所以您将拥有功能分离的优势，这将有助于您为应用程序开发其他功能。

我会设置一个网站，其中每个功能都有一个单独的文件夹。使其成为一个单独的网站将允许所有功能共享相同的母版页、用户控件和配置文件 - 而无需做任何特别的事情。（在此说明，我会将您所有的母版页单独放在一个文件夹中，并为您的用户控件创建另一个文件夹。

How can I tie the applications together, re-use the master pages and keep it maintainable?

再次...文件夹是这里的最佳选择。文件夹将有助于分离每个功能，使应用程序易于管理。

How can I share certain webcontrols (ASCX) in a proper way?

首先，ascx 文件不是 web 控件。它们是用户控件。 WebControl 是一个用于创建驻留在单独程序集中的服务器控件的类。关于用户控件，正如我上面所说，如果您将它们放在单独的文件夹中，它们总是在一个地方并且在整个应用程序中都可用。

We are using TFS, perhaps any branching/merging ideas?

你在这里真的没有什么特别的事情需要做。关于分支，您可以采取许多不同的路径：

一个是为每个版本创建一个分支。
另一种方法是为您添加的每个新功能创建一个分支（在您的情况下，这与第一个选项几乎相同）。
还有一个是为每个开发者创建一个分支。

当我决定如何分支我的代码时，我会考虑最能保护我的东西。在您的情况下，您需要计划在功能版本之间进行错误修复，因此每个版本之后的一个分支可能最有意义（将其称为您的开发分支）。但是，鉴于功能的分离，一个功能可能不会影响应用程序的其余部分。为了安全起见，您可能不需要这种分支。

【讨论】：

分支太多，你会遇到麻烦。每个版本一个分支就足够了。新功能应该在主干中开发（只要它们不是太大或实验性的）。开发人员的分支是我想看到的（不要去那里）......

【解决方案5】：

您可能会考虑使用 SharePoint。对于 ASP.NET 应用程序交付来说，它是一个相当不错的平台，尤其是当它们共存于 Intranet 环境中时；它免费为您提供很多东西。

当然，它的肘部很粗糙，可以这么说，所以要小心。

【讨论】：

有趣的事实：我们最初是通过 SharePoint 接触这个项目，但是由于我们缺乏 SharePoint 专业知识、复杂的网站构建、有限的全球化选项以及我们将引入的大量自定义代码，我们停止了努力。
是的。 SharePoint 是一个 PITA - 问题是它是最好的，这是最不幸的。你描述的项目听起来确实是它的最佳点，尽管它可能并不甜蜜。

【解决方案6】：

从现在开始使用 MVC 概念。它们为强大的应用程序提供了更多的可扩展性和灵活性。

【讨论】：

【解决方案7】：

我不认为这些应用程序是独立的，而是作为整个门户的模块。

我建议您研究一下 MEF，因为这似乎是一个完美的选择。

http://blogs.msdn.com/hammett/archive/2009/04/23/mef-and-asp-net-mvc-sample.aspx

【讨论】：