使用MVC5的企业级应用程序体系结构的最佳实践是什么？

Question

我想知道基于MVC5的企业级体系结构的最佳实践是什么。我的意思是在一个解决方案中选择多层还是多个项目？或者不止一个解决方案？有什么好的例子吗？

Answer 1

由于我的问题在过去一年里经常被问及，而且我也知道没有确切的答案，所以我决定尽可能提供一个全面的答案。这一答复是根据一些实际项目的经验作出的，专家磋商很少：

1. 首先，需要注意的是，在软件设计过程中，没有什么比正确和错误更好的了。只要一种方法适用于您的项目，并适合您的项目，它是正确的，如果它没有，它是错误的。软件设计没有僵化的原则。有“项目需要和规格”。但总的来说，使用“设计模式和原则”已被接受，使项目更加健壮、可靠和易于维护，并使您的代码松散耦合并具有高度的凝聚力。
2. “软件设计和体系结构”的整个故事是关于如何轻松地管理您的项目以及如何维护您未来的更改。考虑一下哪种方法能给你最好的答案。这对你来说是最好的。不要太看重专业精神！你的项目会随着时间的推移而增长，并且会变得更加成熟。所以想想你的计划吧！
3. 作为第一步，对于企业级应用程序架构，始终尝试遵循“关注点分离”或"SoC“。这意味着项目的不同层应该有不同的层次。强烈建议在您的解决方案中为数据访问层、域实体、业务层和表示层使用不同的项目。在MVC5项目中，最好使用类库项目作为数据访问层、域实体、业务层和表示层的MVC项目。
4. 数据访问层是面向数据库和数据库交互的项目。您可以在此项目中拥有所有实体框架或类似实体。为数据库层分离层意味着在更改项目数据仓库的情况下，唯一需要更改的是更改此项目和业务层上的一些小更改。解决方案中的所有其他项目都保持不变。因此，您可以轻松地从MS迁移到Oracle，或者从实体框架迁移到NHibernate。
5. 域实体是用于定义所有解决方案级接口、类、枚举和变量的项目。这个项目在我的类和方法的整个解决方案中保持完整性。整个解决方案中的所有类都是从该项目中的接口继承的。因此，我有one place来更改我的类或全局变量，这意味着在我的解决方案中很容易维护，对于新加入的项目开发人员来说也很容易理解。
6. 业务层是我把所有业务逻辑(包括业务实体和业务服务)放在这里的地方。关于这一层的整个想法是有一个地方来保存您所有的业务方法和交互。有关数据的所有计算、对象修改和所有逻辑，包括保存、检索、更改等，都应在本节中进行。通过在您的项目中拥有这个层，您可以同时拥有不同的消费者，例如一个本地MVC和一个Web层。或者，您可以根据不同的业务服务消费者规范提供不同的喂养。强烈建议避免将任何业务逻辑放入MVC层的控制器部分。在控制器中拥有任何业务逻辑意味着您使用表示层作为业务逻辑层，这违反了关注点的分离。然后，很难从一个表示层更改为另一个表示层，或者为您的解决方案设置不同类型的使用者。最好将控制器部分尽可能地保持在MVC中。控制器只应具有与视图模型直接相关的逻辑和方法。有关视图模型的更多信息，请参阅第7节。记住一件事，最好基于解决方案对象或业务实体拥有不同的Business类。
7. MVC解决方案中的表示层将是一个MVC项目。但是，对于不同的消费者或技术，解决方案可以有其他类型或多个表示层。例如，在一个解决方案中可以有一个MVC层和一个Web。通常使用表示层来保持它中的所有表示逻辑。表示逻辑不应该有任何与业务逻辑或数据逻辑相关的内容。那么问题是什么是表示逻辑？表示逻辑是与视图模型相关的逻辑。视图模型是为视图或页面定制的对象。在大多数情况下，业务对象不适合在视图中使用。另一方面，表示视图通常需要一些验证逻辑或表示逻辑，例如显示名称与原始对象名称不同。在这种情况下，与业务逻辑相比，更好地保持表示逻辑的分离，使其易于独立地更改表示逻辑或业务逻辑，甚至更容易为不同UI设计切换表示层，或更改业务逻辑，使其具有更多的功能，而无需担心表示逻辑的任何中断。在使用MVC项目作为解决方案的表示层的情况下，所有视图模型都应该放在MVC项目的模型部分，所有的表示逻辑都应该放在项目的控制器部分。
8. 最后要说的是，对于每一种多层解决方案，您都需要对象到对象映射的框架，例如，将业务实体转换为视图模型。有一些用于此目的的工具，如AutoMapper、BLToolkit和EmitMapper。

最后一句话:请评论，评分问题和我的答案，以使它更好！

Answer 2

看看康托索大学。企业级应用程序的优秀示例。

示例Web应用程序演示