asp.net - Web 应用程序 - 组合还是分离？

Question

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

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

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

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

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

Answer 1

正如 Brian 所说，在公开 API 时，您应该尽可能多地 promise 它，这意味着它应该在初始发布后尽可能少地更改。然而，要做出稳定的东西需要事先付出很多努力，所以如果你还没有准备好提交 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 有一个称为“区域”的概念，您可以在其中构建与其余应用程序隔离的应用程序的子部分。据我所知，这些区域可以在与“主”应用程序不同的项目中进行维护。这听起来很像你的要求，所以也许你应该调查一下。

希望这是有道理的。 ;)