对于我们公司，我正在创建一个大型Extranet网站，该网站将包含一组子应用程序。我对解决方案和项目的正确设置感到有点困惑。
我有一个我们称之为Portal的Web应用程序。它包含身份验证/授权类，主页，导航/ URL路由类和主题定义。它还将包含一些基本概述，以便我们的客户快速了解他们的项目状态。
在接下来的一年中，我们将开发和集成更多应用程序与门户网站。可以将其视为功能A，B和C的详细概述和工具。多年来，我们将改进这些应用程序并发布新版本。这些Web应用程序应无缝地适合Portal的导航。我希望他们重用主页和主题。
设置此解决方案的正确方法是什么？ 如何将应用程序绑定在一起，重新使用母版页并保持其可维护性？ 如何以正确的方式共享某些webcontrols（ASCX）？ 我们正在使用TFS，也许是任何分支/合并的想法？
修改
我想在ASP.Net WebForms中创建它，我们在该领域拥有最丰富的经验。但基本上我们可以使用任何东西，我们已经拥有了自己控制的网络服务器（只要它是面向Microsoft的，而不是切换到php或类似的东西:)）
答案 0 :(得分：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有一个名为“Areas”的概念，您可以在其中独立于其他部分构建应用程序的子部分。据我所知，这些区域可以在“主”应用程序的单独项目中维护。这听起来很像你要求的，所以也许你应该调查一下。
希望它有意义。 ;）
答案 1 :(得分：2)
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文件不是webcontrols。它们是用户控制。 WebControl是一个用于创建驻留在单独程序集中的服务器控件的类。关于用户控件，如上所述，如果将它们放在一个单独的文件夹中，它们总是在一个地方并且在整个应用程序中都可用。
We are using TFS, perhaps any branching/merging ideas?
这里真的没什么特别的。关于分支，您可以采取许多不同的路径：
当我决定如何分支我的代码时，我会想到最能保护我的东西。在您的情况下，您需要计划功能发布之间的错误修复，因此每个发布后的一个分支最有意义（称之为您的开发分支）。但是，考虑到功能的分离，一个功能可能不会影响应用程序的其余部分。您可能不需要这种分支是安全的。
答案 2 :(得分：1)
我会考虑让您的系统尽可能松散耦合。当您添加更多应用程序时，您的网站将变得越来越不可靠（因为没有任何组件将在100％的时间内上升，结合这些将降低您的整体可靠性）。因此，您应该构建您的系统以满足非主要服务的需求（例如，我相信亚马逊主页有100个服务，因此它具有容错性）
服务之间的API应尽可能保持稳定，以便实现可以在不破坏耦合的情况下进行更改。您还应该在网络级别（也许是Selenium或类似的？）调查此问题的自动化测试，因为测试单个服务将使您对整体行为的覆盖范围很小。
答案 3 :(得分：1)
您可能会发现查看实现自定义VirtualPathProvider很有用。在我的上一个项目中，我们有多个ASP.NET站点需要共享主题文件（母版页，用户控件，图像，样式表），所以我创建了一个VirtualPathProvider，它允许我们将虚拟文件夹（例如/ Themes）映射到任何物理硬盘上的文件夹（例如C：\ Shared \ SiteThemes）。
这不是微不足道的，但没有花太长时间，也没有造成任何问题。顺便说一下，它是克服WiX中最大组件限制的好方法...请注意，您无法预编译使用VirtualPathProvider的站点。
答案 4 :(得分：1)
从现在起使用MVC Concepts。它们为强大的应用程序提供了更大的可扩展性和灵活性。
答案 5 :(得分：0)
您可能会考虑使用SharePoint。它是ASP.NET应用程序交付的一个相当不错的平台，特别是如果它们在Intranet环境中共存的话;它免费为你提供了很多东西。
当然，它有非常粗糙的肘部，可以这么说，所以要谨慎行事。
答案 6 :(得分：0)
我不认为应用程序是独立的，而是整个门户的模块。
我建议你研究一下MED，因为这似乎是一个完美的选择。
http://blogs.msdn.com/hammett/archive/2009/04/23/mef-and-asp-net-mvc-sample.aspx