使用MVC5的企业级应用程序体系结构的最佳实践是什么? [英] What is the best practice for Enterprise level application architecture using MVC5?

问题描述

我想知道基于MVC5的企业级体系结构的最佳实践是什么.我的意思是在一个解决方案中在多层或多个项目之间进行选择?也许不止一种解决方案?任何好的示例项目?

I was wondering what is the best practice for enterprise level architecture based on MVC5. I mean selection between multiple layer or multiple project in one solution? and or maybe more than one solution? any good example project?

推荐答案

由于我的问题在去年访问了很多次，并且我知道还没有确定的答案，因此我决定提供一个全面的答案，因为尽可能地.该答案基于一些实际的项目经验，并且很少进行专家咨询:

Since my question has been visited a lot in the last year and there is no solid answer as I am aware of that, I decided to provide a comprehensive answer as much as possible. This answer is based on some actual projects experience and with few expert consultations:

1. 首先，重要的是要注意在软件设计中 过程中，没有什么是坚实的对与错.只要一个 方法适用于您的项目并且非常适合，它是right，如果 不是，它是wrong.软件中没有严格的原则 设计.有Project needs and specifications.但是一般来说 已被Design Patterns and Principles品牌接受 投影更多robust，reliable和easy to maintain并制作 您的代码loosely coupled and highly cohesive.
2. Software Design and Architecture的整个故事是关于如何 您可以轻松地管理项目以及如何维护自己的项目 未来的变化.考虑哪种方法可以为您提供最佳答案 他们.那将是最适合您的.不要想太多 Professionalism！您的项目会随着时间的增长而变得越来越成熟. 因此，只考虑您的项目！
3. 第一步，对于企业级应用程序体系结构， 始终尝试遵循Separation of Concerns或SoC.这意味着你 对于项目的不同层，应该具有不同的层.它 强烈建议您在您的计算机中使用其他项目 Data Access Layer，Domain Entities，Business Layer和Presentation Layer的解决方案.在MVC5项目中，最好将Class Library Project用于Data Access Layer，Domain Entities，Business Layer，将MVC项目用于Presentation Layer.
4. Data Access Layer是面对数据库和数据库交互的项目.您可以在该项目中拥有所有的Entity Framework或类似实体.在数据库层之间具有单独的层意味着在更改项目数据仓库的情况下，唯一需要更改的就是更改此项目以及Business Layer上的一些细微更改.解决方案中的所有其他项目均保持不变.因此，您可以轻松地从MS Sql迁移到Oracle或从Entity Framework迁移到NHibernate.
5. Domain Entities是我用来定义所有解决方案的项目 级别的接口，类，枚举和变量.该项目保持 在我对类和方法的解决方案中的完整性.我的 整个解决方案中的所有类均从此接口继承 项目.所以我有一个一个地方来更改我的课程或全球 变量，它表示Easy to Maintain对于我的解决方案的未来 对于新加入该项目的开发人员来说，很容易理解.
6. Business Layer是我放置所有业务逻辑(包括 Business Entities和Business Services.整个想法 这一层有一个地方可以保留所有业务方法，并且 互动.所有计算，对象修改和所有逻辑 关于数据，包括保存，检索，更改等 发生在本节中.通过在项目中包含此层，您可以 可以同时拥有不同的消费者，例如一个 本机MVC和一层Web API.或者您可以提供不同的 根据不同的商业服务消费者提供食物 规格.强烈建议避免放置任何 业务逻辑进入MVC层的控制器部分.有任何 控制器内部的业务逻辑意味着您可以使用演示文稿 层作为业务逻辑层，它违反了Separation of Concerns.然后，从一个表示层更改为另一个表示层或让您拥有不同类型的消费者并不容易 解决方案.最好将MVC中的控制器部分保持尽可能小 可能的.控制器应仅具有逻辑和方法 与View Models直接相关.有关View Models的更多信息 请参阅7部分.要记住的一件事， 根据您的解决方案有不同的Business Services类 对象或Business Entities.
MVC解决方案中的
7. Presentation Layer将是一个MVC项目.但 解决方案可以具有其他类型或不止一个表示层 针对不同的消费者或技术.例如你可能有 一种解决方案中包含一层MVC层和一层Web API.一般使用 表示层，将所有表示逻辑保留在其中. 表示逻辑不应与业务逻辑相关 或数据逻辑.那么问题是什么是Presentation logic? Presentation logic是与视图模型有关的逻辑.查看模型 是为视图或页面定制的对象.在大多数情况下，企业 对象不适合在视图中使用.另一方面， 演示视图通常需要一些验证逻辑或 表示逻辑，例如显示名称与原始名称不同 对象名称.在这种情况下，最好保持表示逻辑 与业务逻辑分开，使更改演示变得容易 逻辑或业务逻辑独立，甚至易于切换 用于不同UI设计或业务变更的表示层 具有更多功能而无需担心中断的逻辑 具有演示逻辑.在使用MVC项目作为 表示层作为解决方案，所有视图模型都应放置在 MVC项目的Models部分，所有表示逻辑应为 放在项目的Controllers部分.
8. 最后要说的是，对于每个多层解决方案，您都需要 对象到对象映射的框架，例如将您的 业务实体以查看模型.有一些用于此的工具 AutoMapper，BLToolkit和EmitMapper之类的目的.

1. First of all, it is important to note that in software design process, there is nothing like solid right and wrong. As long as an approach works for your project and fits well, it is right and if it doesn’t, it is wrong. There are no rigid principals in software design. There are Project needs and specifications. But generally, it has been accepted using Design Patterns and Principles makes project more robust, reliable and easy to maintain and make your code loosely coupled and highly cohesive.
2. The whole story of Software Design and Architecture is about how you could manage your project easily and how you could maintain your future changes. Think about which approach gives you best answer on them. That will be the best for you. Don't think too much about Professionalism! .Your project grows by time and gets more mature. So just think about your project!
3. As a first step and for Enterprise level application architecture, always try to follow Separation of Concerns or SoC. It means you should have different tiers for different layers of your project. It is highly recommended to use different project in your solution for Data Access Layer, Domain Entities, Business Layerand Presentation Layer. In MVC5 project, it is better to use Class Library Project for Data Access Layer, Domain Entities, Business Layer and a MVC project for Presentation Layer.
4. Data Access Layer is the project that faces to database and database interactions. You could have all your Entity Framework or similar entities in this project. Having separated layer for database layer means in the case of changing your project data warehouse, the only thing you need to change is changing this project and some minor changes on your Business Layer. All other projects in your solution remain intact. So you could easily move from MS Sql to Oracle or from Entity Framework to NHibernate.
5. Domain Entities is the project I use to define all my solution level interfaces, classes, enums and variables. This project keeps integrity throughout my solution on my classes and my methods. My all classes in whole solution are inherited from interfaces in this project. So I have one place to change my classes or global variables and it means Easy to Maintain for future in my solution and easy to understand for newly joined developers to the project.
6. Business Layer is the place I put my all business logic including Business Entities and Business Services. The whole idea about this layer is having one place to keep your all business methods and interactions. All calculations, object modification and all logic about data including saving, retrieving, changing and so on should happen in this section. By having this layer in your project, you could have different consumers at the same time, for example one native MVC and one Web API layer. Or you could provide different feeding based on different business services consumers specifications. It is highly recommended to avoid putting any business logic into controller section of MVC layer. Having any business logic inside controllers means you using your presentation layer as business logic layer and it violates Separation of Concerns. Then it won’t be easy to change from one presentationlayer to other or having different type of consumers for your solution. It is better to keep controller section in MVC as slim as possible. The controllers should only have logic and methods directly related to View Models. For more information about View Models refer to section 7. One thing to remember, It is better to have different Business Services classes based on your solution objects or Business Entities.
7. Presentation Layer in MVC solution will be an MVC project. But solution could have other type or more than one Presentation Layers for different consumers or technology. For example you could have one MVC layer and one Web API in one solution. Generally Use Presentation Layer to keep all presentation logic in it. Presentation logic shouldn’t have anything related to business logic or data logic. So question is what is Presentation logic? Presentation logic is logic related to view models. View models are objects customized for views or pages. In most cases, business objects are not suitable to use in views. On the other hand, presentation views usually need some validation logic or presentation logic, for example display name different than original object names. In these cases it is better keep presentation logic separated than business logic to make it easy to change presentation logic or business logic independently and even easy to switch presentation layer for different UI design or changing business logic for having more functionality without fear of any interruption with presentation logic. In the case of using MVC project as presentation layer for solution, all view models should be places in Models section of MVC project and all presentation logic should be placed in Controllers section of project.
8. The last thing to say is for every multi-tier solution, you need frameworks for object to object mapping, for example to convert your business entity to view model. There are some tools for this purposes like AutoMapper, BLToolkit, and EmitMapper.

---

最后一个字:请对question和我的answer进行评论并打分，以使其变得更好！

---

Last word: please comment and score question and my answer to make it better!

这篇关于使用MVC5的企业级应用程序体系结构的最佳实践是什么?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！