Web 应用程序 - 组合还是分离？
我正在为我们公司创建一个大型外联网网站，其中包含一组子应用程序。我对解决方案和项目的正确设置应该是什么感到有点困惑。
我有一个 Web 应用程序，我们称之为 Portal。它包含身份验证/授权类、母版页、导航/URL 路由类和主题定义。它还将包含一些基本概述，以便我们的客户快速了解他们的项目状态。
在来年，我们将开发更多应用程序并将其与门户集成。将其视为详细的概述和称为功能 A、B 和 C 的工具。多年来，我们将改进这些应用程序并发布新版本。这些 Web 应用程序应该无缝地融入门户的导航中。我希望他们重用母版页和主题。
设置此解决方案的正确方法是什么？
如何将应用程序绑定在一起、重用母版页并保持其可维护性？
如何以正确的方式共享某些网络控件（ASCX）？
我们正在使用 TFS，也许有任何分支/合并的想法？
编辑：
我想在 ASP.Net WebForms 中创建它，我们在该领域拥有最丰富的经验。但基本上我们可以使用任何东西，我们已经将网络服务器置于我们自己的控制之下（只要它是面向微软的，而不是切换到php或类似的东西:)）
For our company I'm creating a big Extranet website which will feature a set of sub-applications. I'm a bit puzzled by what should be the right setup of the solution and projects.
I have one web application that we call the Portal. It contains the authentication/authorization classes, masterpages, navigation/url routing classes and theme definitions. It will also contain some basic overviews for our customers to get a quick idea of their project status.
In the coming year we are going to develop and integrate more applications with the portal. Think of it as detailed overviews and tools called Feature A, B and C. Over the years we will improve these applications and release new versions. These web applications should fit into the navigation of the Portal seamlessly. I'd like them to reuse the masterpages and themes.
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?
We are using TFS, perhaps any branching/merging ideas?
Edit:
I'd like to create it in ASP.Net WebForms, we have the most experience in that area. But basically we can use anything, we've got the webserver under our own control (as long as it is Microsoft oriented, not switching to php or something like that :))
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
设置此解决方案的正确方法是什么？正确的方法...有很多。我见过很多应用程序，以及很多不同设置（其中很多我认为“正确”）。您真正要求的是适合您情况的最佳方法。
由于您正在构建门户，因此您将拥有功能分离的优势，这将有助于您为应用程序开发其他功能。
我会为每个功能设置一个带有单独文件夹的网站。使其成为一个网站将允许所有功能共享相同的母版页、用户控件和配置文件 - 无需执行任何特殊操作。 （在这一点上，我会将所有母版页单独放在一个文件夹中，并为您的用户控件创建另一个文件夹）。
如何将应用程序绑定在一起、重用母版页并保持其可维护性？再说一次......文件夹是这里的最佳选择。文件夹将有助于区分每个功能，使应用程序易于管理。
如何以正确的方式共享某些 Webcontrols (ASCX)？首先，ascx 文件不是 Webcontrols。它们是用户控件。 WebControl 是一个用于创建驻留在单独程序集中的服务器控件的类。关于用户控件，正如我上面所说，如果将它们放在单独的文件夹中，它们始终位于一个位置并且在整个应用程序中可用。
我们正在使用 TFS，也许有任何分支/合并的想法？这里确实没有什么特别需要做的。关于分支，您可以采取多种不同的路径：
当我决定如何对代码进行分支时，我会考虑什么最能保护我。就您而言，您需要计划在功能版本之间进行错误修复，因此也许每个版本之后的一个分支最有意义（将其称为您的开发分支）。然而，考虑到功能的分离，一项功能可能不会影响应用程序的其余部分。您可能不需要这种分支来确保安全。
What is the proper way to setup this solution?The proper way... There are so many. I have seen a lot of applications, and a lot of different setups (a lot of which that I would deem "proper"). What you're really asking is for the best way for your situation.
Because you're building a portal, you'll have the luxury of feature separation which will help you as you develop additional features for your application.
I would setup a single website with a separate folder for each feature. Making it a single website will allow all features to share the same masterpages, usercontrols, and configuration file - without having to do anything special. (On that note, I would put all your master pages in a folder by themselves, and create another folder for your usercontrols).
How can I tie the applications together, re-use the master pages and keep it maintainable?Again... folders are the best option here. Folders will help separate each feature, making the application easy to manage.
How can I share certain webcontrols (ASCX) in a proper way?First of all, ascx files are not webcontrols. They are usercontrols. WebControl is a class for creating server controls that reside in a separate assembly. Regarding usercontrols, as I said above, if you put them in a separate folder, they're always in one place and available throughout the application.
We are using TFS, perhaps any branching/merging ideas?There really isn't anything special you need to do here. There are a lot of different paths you can take regarding branching:
When I decide how I am going to branch my code, I think about what will protect me the most. In your case, you need to plan for bug fixes in between feature releases so maybe one branch after each release makes the most sense (call it your dev branch). Given the separation of features, though, one feature may not effect the rest of the application. You may not need this kind of branching to be safe.
正如 Brian 所说，当公开 API 时，您应该尽可能多地致力于它，这意味着在初始发布后它应该尽可能少地更改。然而，要使某些东西变得稳定，需要预先付出大量的努力，因此，如果您还没有准备好致力于 API，您应该尽可能地将其内部化，因此您可能希望将事物组合起来而不是将它们分开。
但是，我不会根据 5 段描述来建议适合您的应用程序的架构。您需要做的是权衡拥有几个大项目与拥有一堆松散耦合的小项目的利弊。我的意思是，如果你坚持执行计划，你预先做的计划越多，你就越容易完成它。
因此，与布莱恩的回答相反，我不建议您使整个系统“尽可能松散耦合”，而只是根据需要使其松散耦合。 ;) 如果您滥用松散耦合的代码，它可能会导致与紧密耦合的代码一样多的麻烦。
参见：
1. 哪个更好，多个小型组件，还是一个大集会？
2. 许多“小型”组件的具体缺点？
最后，只有您知道您想在多大程度上关注每个“...能力”、可维护性、可扩展性、可靠性等。因此，请明确您的优先事项和目标并进行相应的计划。
关于分支策略，您可以阅读 TFS 分支指南 2.0，其中很好地介绍了各种分支策略，包括基础到高级。即使您不使用 TFS，这也是一个很好的阅读指南（我目前使用 SVN）。由于我目前在拥有 1-4 名开发人员的小团队中工作，因此我倾向于使用介于基本和标准之间的策略。我并不是在向您推荐这个，而是最适合我们团队的。
至于项目之间共享代码。在SVN中我们可以使用“externals”，这意味着共享文件将出现在多个文件夹中，因此当您更改一个副本并将更改提交到 svn 时，所有其他副本将在下一次 svn 更新时更新。不过，我不记得TFS是否有类似的东西。
注意：小心 SVN 中的外部因素...它们可能会导致...问题。 ;)
我的建议是尽量避免共享 aspx、ascx 和母版页。通常它带来的伤害远大于它所带来的帮助。相反，尝试使用继承或其他替代方案来实现您的目标。
ASP.NET MVC 2.0 有一个称为“区域”的概念，您可以在其中独立于其余部分构建应用程序的子部分。据我所知，这些区域可以在与“主”应用程序不同的项目中进行维护。这听起来很像你所要求的，所以也许你应该研究一下。
希望这是有道理的。 ;)
As Brian says when making an API public you should commit to it as much as possible, which means it should change as little as possible after the initial release. However to make something that stable requires lots of effort up front so if you aren't ready to commit to the API you should instead internalize it as much as possible and for that reason you might want to combine things more than separating them.
However, I'm not going to suggest an architecture that fits your application based on a 5 paragraph description. What you need to do is to weight pros and cons of having a few big projects vs. having a bunch of loosely coupled small projects. I mean, the more planning you do up front, the easier you will have it down the line, provided you stick with the plan.
So contrary to Brians answer, I wouldn't recommend you make your entire system "as loosly coupled as possible", only that you make it as loosly coupled as it needs to be. ;) Loosely coupled code can cause as much trouble as tightly coupled code, if you are abusing it.
See:
1. What is better, many small assemblies, or one big assembly?
2. Specific down-sides to many-‘small’-assemblies?
In the end, only you know how much you want to focus on each of the "...bilities", maintainability, extensibility, reliability etc. So get your priorities and goals straight and plan accordingly.
Regarding branching strategies you could read the TFS Branching Guideline 2.0 which have a good introduction to various branching strategies ranging from basic to advanced. Even if you don't use TFS this is a good guide to read (I use SVN at the moment). Since I currently work in small teams with 1-4 devs, I tend to use a strategy that is between basic and standard. Not that I'm recommending this for you, but that whats works best for our team.
As for sharing code between projects. In SVN we can use "externals" which means that the shared file will appear in several folders so when you change one copy and commit the change to svn, all the other copies will be updated on the next svn update. However, I can't remember if TFS have something similar.
Note: Beware of externals in SVN... they can cause... problems. ;)
My advice is to try to avoid sharing aspx, ascx and master pages as much as possible. It usually hurts a lot more than it helps. Instead try to use inheritance or other alternatives to achieve your goal.
ASP.NET MVC 2.0 has a concept called "Areas" where you build subsections of an application in isolation from the rest. As far as I know these areas can be maintained in separate projects from the "main" application. It sounds a lot like what you are requesting so maybe you should look into that.
Hope it makes sense. ;)
我会考虑使您的系统尽可能松散耦合。当您添加更多应用程序时，您的网站将变得越来越不可靠（因为没有任何组件会 100% 正常运行，因此将这些组件结合起来会降低您的整体可靠性）。因此，您应该构建自己的系统来满足出现故障的非主要服务的需求（例如，我相信亚马逊主页有 100 多个服务对此做出贡献，因此它的构建是为了容错）。
服务之间的 API应尽可能保持稳定，以便可以在不破坏耦合的情况下更改实现。您还应该在 Web 级别研究对此的自动化测试（也许 Selenium 或类似的？），因为测试各个服务将对整体行为的报道很少。
I would look at making your system as loosely coupled as possible. As/when you add more applications, your website will become less and less reliable (since no component will be up 100% of the time, combining these will reduce your overall reliability). So you should build your system to cater for the non-major services being down (I believe the Amazon homepage, for example, has 100-ish services contributing to it, and as such it's built to be fault-tolerant)
Your APIs between services should remain as stable as possible, such that the implementations can change without breaking the coupling. You should also investigate automated testing of this at the web level (perhaps Selenium or similar?) since testing the individual services will give you little coverage re the overall behaviour.
您可能会发现查看实现自定义 VirtualPathProvider 很有用。在我的上一个项目中，我们有多个 ASP.NET 站点需要共享主题文件（母版页、用户控件、图像、样式表），因此我创建了一个 VirtualPathProvider，它允许我们将虚拟文件夹（例如 /Themes）映射到任何物理文件夹硬盘上的文件夹（例如 C:\Shared\SiteThemes）。
这不是一件小事，但并没有花费太长时间，也没有造成任何问题。顺便说一句，事实证明这是克服 WiX 中最大组件限制的好方法...请注意，您无法预编译使用 VirtualPathProvider 的站点。
You might find it useful to look at implementing a custom VirtualPathProvider. On my last project we had multiple ASP.NET sites which needed to share theme files (master pages, user controls, images, style sheets) so I created a VirtualPathProvider which allowed us to map a virtual folder (e.g. /Themes) to any physical folder on the hard drive (e.g. C:\Shared\SiteThemes).
It's not trivial but didn't take too long and hasn't caused any problems. Incidentally it turned out to be a great way to overcome the maximum component limit in WiX... Note that you can't precompile sites that use a VirtualPathProvider.
从现在开始使用 MVC 概念。它们为强大的应用程序提供了更多的可扩展性和灵活性。
Use MVC Concepts from now. they give more extendability and flexibility for a robust applications.
您可能会考虑使用 SharePoint。对于 ASP.NET 应用程序交付来说，它是一个相当不错的平台，特别是当它们共存于 Intranet 环境中时；它免费为您提供很多东西。
当然，可以说它的肘部非常粗糙，因此请谨慎行事。
You might look at using SharePoint. It's a pretty decent platform for ASP.NET application delivery, particularly if they coexist in an intranet environment; it gives you a lot of stuff for free.
Of course, it has very rough elbows, so to speak, so proceed with caution.
我不会将应用程序视为单独的，而是将其视为整个门户的模块。
我建议您研究一下 MEF，因为这似乎是一个完美的选择。
http:// blogs.msdn.com/hammett/archive/2009/04/23/mef-and-asp-net-mvc-sample.aspx
I wouldn't think of the applications as seperate but as modules of the overall portal.
I would recommend you look into MEF as this would seem to be a perfect fit.
http://blogs.msdn.com/hammett/archive/2009/04/23/mef-and-asp-net-mvc-sample.aspx