问题描述
我开始计划一个大的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身份验证的基于Intranet的Web站点，在IIS上运行，并使用SQL Server和ASP.NET。这将需要进行结构与那些可插拔的基础上的一些配置设置的子应用的主/外壳应用程序。
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.
例如，我们将有一个报告应用程序，显示应用，而且很可能其他几个不同的应用程序。在主/外壳应用程序启动，确定用户是谁后，主要的应用程序会查询数据库，以确定哪些子Apps中的用户可以使用和打造出来的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.
最后，整个应用程序和所有子应用程序需要一个分层的设计，presentation，服务，业务和数据访问层，以及东西，如伐木交叉对象，异常处理，等等。
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？ EF？ NHibernate的？企业库？ Repository模式？其他？？？？我知道所有这些技术/框架不用于同样的目的，但我们知道把重点放在哪些是有点势不可挡。
哪些将是一个解决方案的最佳选择（S）？哪些要求结束对终端的设计很好地协同工作？
一个人怎么会构建了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?
谢谢！
推荐答案
我相信可插拔子应用程序注册 - 它绝对是在.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.
记住要使用并的，但是这取决于项目和建筑，所以你需要阅读一些评论，有很多人在互联网上。
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框架将是您的解决方案最佳。此外，我认为，它应该在数据访问层位于并且不影响应用程序的其他层。这是不错的主意，使用在顶层，让您的商务逻辑/ UI完全独立于DAL。
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.
此外，它是不错的主意，实现一些公共服务层，如身份验证，在主要的主机应用程序日志等，让他们共同为每个扩展应用。 BTW，用于记录我通常使用。
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应用程序的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！