使用MVC5的企业级应用程序架构的最佳实践是什么?

时间:2015-09-18 00:05:18

标签: architecture asp.net-mvc-5 enterprise solution

我想知道基于MVC5的企业级架构的最佳实践是什么。我的意思是在一个解决方案中选择多层或多个项目?或者可能不止一个解决方案?任何好的示例项目?

2 个答案:

答案 0 :(得分:30)

由于我的问题在去年被访问了很多,而且我没有确切的答案,所以我决定尽可能提供全面的答案。这个答案是基于一些实际的项目经验和很少的专家咨询:

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

答案 1 :(得分:-1)

看看Contoso University。企业级应用的优秀示例。

Sample Web Application Demonstration

相关问题