asp.net-mvc - 没有存储库和 UoW 模式的 ASP.NET MVC 5 中的服务层和项目结构

Question

我想使用 EF 6 代码优先概念在 ASP.NET MVC 5 中创建一个优秀的应用程序。我希望它经过精心设计，即一般来说:表示层、逻辑层和数据层是分开的。我希望它是可测试的:)

这是我的想法以及与创建应用程序相关的一些问题

表示层:这是我的整个 MVC - View 模型(不是模型)、 View 、 Controller 我认为验证应该在其他地方完成(在我看来 - 这是业务逻辑的一部分)，但是使用 ViewModelds 中 DataAnnotations 命名空间中的属性并检查 Controller 中的验证非常方便。

逻辑层:服务 - 类及其接口(interface)来规则业务逻辑。我放了这样的函数:AddNewPerson(PersonViewModel Person)、SendMessageToPerson(...)。他们将使用数据库上下文来执行操作(有可能并非所有人都依赖上下文)。服务和数据库之间有直接连接 - 我的意思是服务类具有引用上下文。我应该在哪里进行 ViewModel 和 Model 之间的映射？我听说服务是一个不好的地方 - 所以也许在 Controller 中。我听说服务应该专门完成与数据库相关的工作。这样对吗？我的服务层图好吗？

数据层:我读过很多有关存储库和 UoW 模式的内容。有一些文章表明 EF6 实现了这两件事。如果不需要这种行为，我不想创建额外的代码。问题是:我认为我不需要它们是否正确？

这是我的流程:

View <-> Controller (使用ViewModel)<->服务(使用模型)<->数据库。

**我将在我的项目中使用 DI。

您对我的项目结构有何看法？

Answer 1

如果您不需要创建通用数据访问机制，则没有理由将工作单元模式与 Entity Framework 一起使用。仅当您满足以下条件时才会执行此操作:

1. 使用本身不支持工作单元模式(EF 支持)的数据访问技术
2. 希望能够在未来的某个时候更换数据提供者..然而，这并不像看起来那么容易，因为即使在使用工作单元时也很难不引入对特定数据技术的依赖(也许即使因为你是)...或
3. 您需要有一种方法将不同的数据源统一到原子事务中。

如果情况并非如此，您很可能不需要自定义工作单元。另一方面，存储库可能很有用...但对于 EF6，存储库的许多优点也可用，因为 EF6 提供了用于测试的模拟接口(interface)。无论如何，请远离通用存储库，除非它只是具体存储库的实现细节。将通用存储库暴露给其他层是一个巨大的抽象泄漏......

我总是使用存储库/服务/外观模式来在数据层和业务层(以及 UI 层和业务层)之间创建分离。它提供了一种方便的模拟方法，而无需模拟您的数据访问本身，并将您的逻辑与 EF 使用的 Linq 层引入的特定逻辑解耦(Linq 相对通用，但有些东西是 EF 特有的)，外观/存储库/服务器接口(interface)将其解耦)。

总的来说，您走在正确的道路上...但是，让我指出，在 View 模型上使用数据属性是一件好事。这将您的验证集中在模型上，而不是让您将验证逻辑放在各处。

您的业务逻辑也需要验证，这是正确的，但您的错误是假设您应该只在业务逻辑上进行验证。您需要在应用程序的所有层进行验证。特别是，您的 UI 验证可能与业务逻辑验证有不同的要求。

例如，您可以在 UI 中将创建新帐户实现为多步骤向导，这将需要与业务层不同的验证，因为每个步骤仅包含整个对象验证的子集。或者您可能要求您的移动界面具有与您的网站不同的验证要求(例如，一个可能使用验证码，而另一个可能使用基于触摸的人工验证)。

无论哪种方式，请务必记住，验证在客户端、服务器和各个层都很重要......