我开始为大型Web应用程序规划一个架构，我想获得有关从哪里开始以及使用哪些技术和/或框架的建议和/或建议。
该应用程序将是一个使用Windows身份验证的基于Intranet的网站，在IIS上运行并使用SQL Server和ASP.NET。它需要构建为主/ shell应用程序，其子应用程序基于某些配置设置是“可插拔的”。
主要或shell应用程序是提供整体用户界面结构 - 页眉/页脚，为每个可用子应用程序动态构建的选项卡，以及在用户单击时将加载子应用程序的内容区域子应用程序的选项卡。因此，在启动主/ shell应用程序时，将从数据库中查询配置信息，并且基于用户和哪些子应用程序可用，主应用程序或shell应用程序将动态构建选项卡（或按钮）或某事）作为访问每个单独的应用程序的方式。在启动时，内容区域将填充“主页”子应用程序。但是，单击子应用程序选项卡将导致使用与选项卡对应的子应用程序填充内容区域。
例如，我们将有一个报告应用程序，一个显示应用程序，以及可能还有其他几个不同的应用程序。在启动主/ shell应用程序时，在确定用户是谁之后，主应用程序将查询数据库以确定用户可以使用哪些子应用程序并构建UI。然后，用户可以在可用的子应用程序之间导航，并在每个应用程序中进行工作。
最后，整个应用程序和所有子应用程序需要是一个分层设计，包括演示文稿，服务，业务和数据访问层，以及日志记录，异常处理等事务的交叉对象。 / p>
无论如何，我的问题围绕着从哪里开始规划像这个应用程序这样的东西。
哪些技术/框架在为此应用程序开发解决方案时最有效？ MVC？ MVP？ WCSF？ EF？ NHibernate的？企业图书馆？存储库模式？其他？？？？我知道所有这些技术/框架都没有用于同一目的，但知道要关注哪些技术/框架有点压倒性。 哪些是解决方案的最佳选择？对于端到端设计，哪些可以很好地协同工作？ 如何为这样的东西构建VS项目？
谢谢！
答案 0 :(得分：0)
我认为ASP.Net MVC是此类项目的最佳基本框架。它非常灵活且可自定义，因此您可以在ASP.Net MVC顶部为您的应用程序构建自己的高级框架。
此外，我还建议您使用MEF进行可插入的子应用程序注册 - 它绝对是.Net中扩展的最佳框架。
请记住使用IoC/Dependency Injection containers尽可能保持您的解决方案组件彼此独立。我最喜欢的是Structure Map和Autofac，但这取决于项目和架构，所以你需要阅读一些评论，互联网上有很多评论。
我无法告诉您哪种ORM框架最适合您的解决方案。此外，我相信它应该位于数据访问层，不会影响应用程序的其他层。最好在顶层使用DTO (Data-Transfer-Object)，以使您的业务逻辑/ UI完全独立于DAL。
另外，在主要主机应用程序中实现一些公共服务层（如身份验证，日志记录等）并使它们在每个扩展应用程序中都是通用的。顺便说一句，对于日志记录，我通常使用log4net。