我是否了解 ASP.NET MVC 和实体框架的架构设计？答案

【问题标题】：Have I understood architectural design with ASP.NET MVC and Entity Framework?我是否了解 ASP.NET MVC 和实体框架的架构设计？
【发布时间】：2017-06-12 12:58:43
【问题描述】：

我目前正在开发一个使用 Active Directory 和 SQL Server 2008 的 Intranet 网站。我选择了 ASP.NET 的 MVC 设计模式，现在正试图弄清楚如何为我的项目涉及使用 Entity Framework 的数据访问部分。为了不走错方向，我已经挣扎了好几天（知道我是我公司唯一的开发人员，这是我的第一次体验，没有人知道最近的框架）。我已经阅读了有关架构以及如何正确使用它的信息，但我不确定我是否正确掌握了所有内容 (How do architect an ASP.Net MVC app with EF?)。

这是我想做的事情，每一层都有自己的项目（请原谅我的绘画技巧）：

Controller(MVC Project) ---uses---> Service Layer (Project) ---uses--> EFDal (Project)
               ^                         |        ^                          |
               |                         |        |                          |
               |<-------<-----returns ViewModel   |<---------<------returns Query Result

EFDal 是 EntityFramework 数据访问层。

据我了解，服务层将包含调用 DAL 的方法，而 DAL 又用于访问数据。

您认为我的方法有问题吗？
我说的服务层是否正确，它包含所有操作吗？（例如：在 DB 中搜索用户 -> 服务层通过调用返回值的 EFDal 启动搜索，然后服务层向控制器返回 ViewModel）（另见：Creating a Service Layer for my MVC application?）

最后，我的服务层类是否应该为持久性目的实现接口？

作为学生，我们只在我们的项目中使用 MVC 模式，因为我们从事的是小型项目，所以从来不需要用新项目扩展解决方案。在这里，我觉得对架构的误解最终会导致灾难性的可维护性。感谢您的帮助！

【问题讨论】：

有很多可能的架构取决于应用程序的大小。对于较小的应用程序，您可能会使用引用 EF 的单个 MVC 项目。我们的大多数都是中型的，我们为 EF 内容（上下文、流利、迁移）创建 App.Data，为我们的 POCO 模型创建 App.Entities，为我们的 UI 创建 App.MVC，然后使用 Automapper 创建我们的 ViewModel。 CQRS 是另一种选择。
@SteveGreene 谢谢你的回答。这就是我想要的。虽然从未使用过 Automapper，但不确定我是否需要它，我所有的数据库表都非常简单，我只有很多。至少从我所了解的 Automapper 用于复杂对象？我真的不能说这个应用程序有多大，但是公司有 4500 名员工（还有一个实习生在做这种事情……），还有许多不同的操作需要通过 Active Directory 或 SQL Server 进行管理，所以我需要表现不错。
性能和架构通常需要权衡取舍。 EF 不是性能最高的数据访问技术。见here。这是选择 Dapper 的原因之一。
@SteveGreene 有趣的帖子，尽管他们确实说优化 EF 请求确实可以提高性能。但我确实需要一个高性能的数据访问，因为该项目的基础之一是让它比已经投入生产的更快。我会检查一下 Dapper，看看哪个最适合我的需要，谢谢！
EF 对于我们最大的应用程序来说也足够强大，但 Stack Overflow 类型的体积是另一回事。

标签： c# sql-server asp.net-mvc entity-framework

【解决方案1】：

你几乎是在正确的方向。但是，在这种情况下，ViewModel 应该驻留在应用程序层中，即您的 MVC 层。服务层应该反过来返回一个数据传输对象，通常称为DTO。

将ViewModel 视为为View 构建的简单POCO 类，它可以是各种服务从服务层返回的各种DTO 的集合。

DTO的好处

您没有直接公开您的域实体，即您的 EntityFramework POCO 类。但是，可以为一个小到足以避免DTO 的项目创建一个案例。
如果将来您决定在您的MVC 项目中添加一个WebAPI 函数，例如用于iPhone 应用程序。新应用程序使用同样消耗服务层的WebAPI，大多数服务层代码可以重复使用，因为它们返回DTO 类，而不是为View 本身构造的ViewModel。李>

对于您的数据访问层，没有人能比这个人解释得更好。 Entity FrameWork With Repository Pattern

至于项目结构，我建议使用洋葱架构。 Onion Architecture。如果你能很好地理解这篇文章，你应该已经准备好了。

【讨论】：

洋葱链接坏了
@IvanJazz 好的，谢谢！我将立即阅读这些文章（以及 Mosh 的视频，总是很重要！）。那么 ViewModel POCO 将创建服务层类的实例，对吗？在服务层内部我有一个类及其对应的接口？
@Flexabustbergson ViewModel POCOs 由 MVC 应用程序的控制器通过从服务层调用各种服务来构造。如果您打算真正将您的应用程序与其服务分离，那么是的，为每个服务提供接口是可取的，因为它有助于单元测试和模拟。
@IvanJazz 在您发布的洋葱架构文章中有一点我不明白：在第一个文件夹 01-Domain 中，我所有的 DB POCO 都将去哪里？我应该为每个数据库添加一个新项目吗？如果我有其他业务逻辑，我应该把它放在那里，每个类都有一个接口？
@Flexabustbergson 是的，您的 DB POCO 位于 Domain.Entities 中。业务逻辑是项目服务中的服务层的一部分。您不必完全按照文章的内容进行操作，主要内容是每个项目的依赖关系，即您添加到每个项目的正确引用。