具有子应用程序的 Web 应用程序的架构建议/推荐 [英] Architecture Suggestions/Recommendations for a Web Application with Sub-Apps

问题描述

我开始为大型 Web 应用程序规划架构，我想获得有关从哪里开始以及使用哪些技术和/或框架的建议和/或建议.

I’m starting to plan an architecture for a big web application, and I wanted to get suggestions and/or recommendations on where to begin and which technologies and/or frameworks to use.

该应用程序将是一个使用 Windows 身份验证、在 IIS 上运行并使用 SQL Server 和 ASP.NET 的基于 Intranet 的网站.它需要被构建为一个主/外壳应用程序，其中包含基于某些配置设置的可插入"子应用程序.

The application will be an Intranet-based web site using Windows authentication, running on IIS and using SQL Server and ASP.NET. It’ll need to be structured as a main/shell application with sub-applications that are "pluggable" based on some configuration settings.

主应用程序或外壳应用程序是提供整体用户界面结构——页眉/页脚、为每个可用子应用程序动态构建的选项卡，以及当用户单击子应用程序时将在其中加载子应用程序的内容区域子应用程序的选项卡.因此，在启动主/外壳应用程序时，将从数据库中查询配置信息，并根据用户和哪些子应用程序可用，主应用程序或外壳应用程序将动态构建选项卡(或按钮)或其他东西)作为访问每个单独应用程序的方式.在启动时，内容区域将填充主页"子应用程序.但是，单击子应用程序选项卡将导致内容区域填充与选项卡对应的子应用程序.

The main or shell application is to provide the overall user interface structure – header/footer, dynamically built tabs for each available sub-app, and a content area in which the sub-application will be loaded when the user clicks on the sub-application’s tab. So, on start-up of the main/shell application, configuration information will be queried from a database, and, based on the user and which of the sub-apps are available, the main or shell app would dynamically build tabs (or buttons or something) as a way to access each individual application. On start-up, the content area will be populated with the "home" sub-app. But, clicking on an sub-app tab will cause the content area to be populated with the sub-app corresponding to the tab.

例如，我们将有一个报告应用程序、一个显示应用程序，可能还有一些其他不同的应用程序.在主/壳应用程序启动时，主应用程序在确定用户是谁后，会查询数据库以确定用户可以使用哪些子应用程序并构建UI.然后用户可以在可用的子应用之间导航并在每个子应用中完成他们的工作.

For example, we’re going to have a reports application, a display application, and probably a couple other distinct applications. On startup of the main/shell application, after determining who the user is, the main app will query the database to determine which sub-apps the user can use and build out the UI. Then the user can navigate between available sub-apps and do their work in each.

最后，整个应用程序和所有子应用程序都需要分层设计，包括表示层、服务层、业务层和数据访问层，以及用于日志记录、异常处理等事物的横切对象.

Finally, the entire app and all sub-apps need to be a layered design with presentation, service, business, and data access layers, as well as cross-cutting objects for things such as logging, exception handling, etc.

无论如何，我的问题都围绕着从哪里开始计划类似这个应用程序的东西.

Anyway, my questions revolve around where to begin to plan something like this application.

哪些技术/框架最适合为此应用开发解决方案?MVC?MVP?WCSF?英孚?休眠?企业图书馆?存储库模式?其他????我知道所有这些技术/框架都不是用于同一目的，但是知道要关注哪些技术/框架有点让人不知所措.哪些是解决方案的最佳选择?哪些可以很好地协同进行端到端设计?如何为这样的事情构建 VS 项目?

What technologies/frameworks would work best in developing a solution for this application? MVC? MVP? WCSF? EF? NHibernate? Enterprise Library? Repository Pattern? Others???? I know all these technologies/frameworks are not used for the same purpose, but knowing which ones to focus on is a little overwhelming. Which ones would be the best choice(s) for a solution? Which ones work well together for an end-to-end design? How would one structure the VS project for something like this?

谢谢！

推荐答案

我相信 ASP.Net MVC 是此类项目的最佳基础框架.它非常灵活和可定制，因此您可以在 ASP.Net MVC 的顶部为您的应用程序构建自己的高级框架.

I believe that ASP.Net MVC is the best basic framework for such projects. It is very flexible and customizable, so you could build your own high-level framework for your apps at the top of ASP.Net MVC.

另外我想推荐您使用 MEF 进行可插拔子应用程序注册 - 它绝对是.Net 中扩展的最佳框架.

Also I would like to recommend you to use MEF for pluggable sub-applications registration - it is absolutely the best framework for extensions in .Net.

记得使用 IoC/Dependency Injection 容器 以保持您的解决方案组件尽可能独立尽可能相互隔离.我最喜欢的是 Structure Map 和 Autofac，但这取决于项目和架构，所以你需要阅读一些评论，网上有很多评论.

Remember to use IoC/Dependency Injection containers to keep your solution components as much independent from each other as it possible. My favorites are Structure Map and Autofac, but it depends on project and architecture, so you need to read some reviews, there are lots of them in Internet.

我无法告诉您哪种 ORM 框架最适合您的解决方案.此外，我认为它应该位于数据访问层，并且不会影响应用程序的其他层.最好在顶层使用 DTO(数据传输对象) 来保持您的业务完全独立于 DAL 的逻辑/UI.

I can't tell you what ORM framework would be a best for your solution. Moreover, I believe, that it should be located at Data Access Layer and do not affect other layers of your application. It is nice idea to use DTO (Data-Transfer-Object) at top layers to keep your Business logic/UI completely independent from DAL.

此外，在主主机应用程序中实现一些通用服务层(如身份验证、日志记录等)也是一个不错的主意，并使它们对每个扩展应用程序通用.顺便说一句，对于日志记录，我通常使用 log4net.

Also it is nice idea to implement some common services layer like authentication, logging etc. at main host application and make them common for each extension application. BTW, for logging I usually use log4net.

这篇关于具有子应用程序的 Web 应用程序的架构建议/推荐的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！