logo标签列表

Web应用程序 - 合并还是分离？

asp.netweb-applicationsmaster-pagesextranet
4
为我们公司创建一个大型外联网站，其中包含一系列子应用程序。我对解决方案和项目的正确设置感到有些困惑。
我有一个名为Portal的Web应用程序。它包含身份验证/授权类、主页、导航/URL路由类和主题定义。它还将包含一些基本概述，让我们的客户快速了解他们的项目状态。
在未来的一年里，我们将开发和集成更多的应用程序到门户中。可以把它看作是称为功能A、B和C的详细概述和工具。在未来的几年里，我们将改进这些应用程序并发布新版本。这些Web应用程序应无缝地适应门户的导航。我希望它们能够重用主页和主题。
如何正确设置此解决方案？如何将应用程序联系起来，重用主页并保持可维护性？如何以适当的方式共享某些Web控件（ASCX）？我们使用TFS，也许有分支/合并的想法吗？
编辑：我想在ASP.Net WebForms中创建它，我们在那个领域拥有最丰富的经验。但基本上我们可以使用任何东西，只要它是面向Microsoft的，而不是切换到PHP或其他什么的。
你想使用特定的框架吗？Webforms、asp.net mvc还是其他什么？ - Mattias Jakobsson
7个回答
2
正文：
如Brian所说，当公开API时，您应尽可能地致力于它，这意味着在最初发布后应尽可能少地更改。然而，要创建稳定的东西需要大量的前期工作，因此，如果您还没有准备好承诺API，则应尽可能将其内部化，并且出于这个原因，您可能希望将事物组合起来而不是分离它们。
但是，我不会根据5段描述为您的应用程序提供适合的架构建议。您需要做的是权衡拥有少量大型项目与拥有一堆松散耦合的小型项目之间的优缺点。我的意思是，您进行的规划越多，下游处理就越容易，前提是您坚持计划。
因此，与Brian的答案相反，我不建议您使整个系统“尽可能松散耦合”，只建议您将其松散耦合到必要程度。;) 如果滥用它，松散耦合的代码可能会引起与紧密耦合的代码一样多的问题。
见：
1. 许多小程序集与一个大程序集哪个更好？
2. 许多“小”程序集的具体缺点是什么？

最终，只有您知道您想要专注于每个“...能力”的程度，如可维护性、可扩展性、可靠性等。因此，请明确您的优先事项和目标，并相应地进行计划。

关于分支策略，您可以阅读TFS分支指南2.0，其中介绍了从基本到高级的各种分支策略。即使您不使用TFS，这也是一份很好的指南（我目前使用SVN）。由于我目前在1-4名开发人员的小团队中工作，所以我倾向于使用介于基本和标准之间的策略。我并不是在为您推荐这种策略，而是这对我们的团队效果最好。

关于在项目之间共享代码。在 SVN 中，我们可以使用“externals”这个功能，这意味着共享文件将出现在几个文件夹中，因此当您更改一个副本并将更改提交到 SVN 时，所有其他副本将在下一次 SVN 更新时更新。但是，我不记得 TFS 是否有类似的功能。
请注意：小心 SVN 中的 externals…它们可能会引起问题。 ;)
我的建议是尽量避免共享 aspx、ascx 和 master 页面。通常它会带来比帮助更多的痛苦。而是尝试使用继承或其他替代方案来实现您的目标。
ASP.NET MVC 2.0 有一个称为“区域”的概念，您可以在其中独立地构建应用程序的子部分。据我所知，这些区域可以在与“主”应用程序不同的项目中维护。这听起来很像您所请求的内容，因此您可能应该进一步了解一下。
希望这有意义。;)
2

如何设置这个解决方案的正确方式？

有很多种“正确”的方式。我看过很多应用程序，也看过很多不同的设置（其中很多我认为是“正确的”）。你真正想问的是最适合你情况的最佳方法。

因为你正在构建一个门户网站，你将拥有特性分离的便利，这将在你开发应用程序的其他功能时帮助你。

我会设置一个单独的网站，每个特性都有一个单独的文件夹。这样做可以让所有特性共享相同的主页、用户控件和配置文件，无需进行任何特殊设置。（另外，我会把所有的主页放在一个文件夹中，为用户控件创建另一个文件夹）。

如何将应用程序联系在一起，重复使用主页面并保持可维护性？

同样……文件夹是最好的选择。文件夹将有助于分离每个特性，使应用程序易于管理。

如何以正确的方式共享某些WebControls（ASCX）？

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

我们正在使用TFS，也许有分支/合并的想法吗？

在这里真的没有什么特别需要做的事情。关于分支，有很多不同的路径可以选择：

  • 一种是为每个发布创建一个分支。
  • 另一种是为您添加的每个新功能创建一个分支（在您的情况下，这基本上与第一种选项相同）。
  • 还有一种是为每个开发人员创建一个分支。

当我决定如何分支我的代码时，我会考虑什么最能保护我。在你的情况下，你需要计划在特性发布之间进行错误修复，所以也许在每次发布后创建一个分支是最明智的选择（称其为你的开发分支）。然而，鉴于特性的分离，一个特性可能不会影响应用程序的其他部分。你可能不需要这种类型的分支来保持安全。

过多的分支会让你陷入麻烦。每个发布版本一个分支应该足够了。新功能应该在主干上开发（只要它们不是太大或实验性的）。对于开发人员来说，我希望看到分支（不要去那里）... - Bojan Milenkoski
1

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

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

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

我建议您尽可能使系统松耦合。随着您添加更多应用程序，您的网站将变得越来越不可靠（因为没有组件会一直处于100％的状态，将它们结合起来将降低您的整体可靠性）。因此，您应该构建系统以适应非主要服务停机的情况（例如，我相信亚马逊首页有大约100个服务贡献，因此它被构建为容错）。

服务之间的API应尽可能保持稳定，以便实现可以更改而不会破坏耦合。您还应该调查在Web层面上进行自动化测试（也许使用Selenium或类似工具？），因为测试单个服务将无法涵盖整体行为。

0
你可以考虑使用SharePoint。它是一个相当不错的ASP.NET应用程序交付平台，特别是在Intranet环境下共存时；它会给你很多免费的东西。
当然，它也有非常棘手的问题，所以请小心操作。
有趣的是，我们最初采用SharePoint来进行这个项目，然而，由于我们缺乏SharePoint专业知识、复杂的网站建设、有限的全球化选项和大量引入的自定义代码，我们最终放弃了这个尝试。 - Yvo
是的，SharePoint真是个让人头疼的东西——问题在于它是最好的，这是非常不幸的。你描述的项目听起来确实像是它的优势所在，尽管可能并不那么甜美。 - Ben Collins
0
网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接