MVC3 应用程序/服务层/存储库层/POCO 类/EF4 - 问题！

Posted 2023-02-24

【中文标题】MVC3 应用程序/服务层/存储库层/POCO 类/EF4 - 问题！

【英文标题】：MVC3 App/Service Layer/Repository Layer/POCO Classes/EF4 - Questions!

【发布时间】：2011-07-05 10:25:22

【问题描述】：

我对整个设计概念很陌生，在过去几周的阅读中，我收集了很多信息，但似乎分散和矛盾。术语混杂在一起，我只是很难理解这一点。

我使用的模式是这样的，假设流程如下：

MVC 应用程序 控制器处理来自客户端对给定视图的请求/响应。在控制器操作方法中，它们联系服务（服务层）并请求对象来构建视图模型，然后将视图模型中的对象发送回来。

查看模型 我在视图之间使用强类型视图模型。

视图模型是 DTO 吗？它们应该只包含简单的属性，如 Name、AddressLine1、Address City 等，还是应该包含复杂的属性、多个对象等。

是视图模型中的验证。如果是这样，是否会像必填字段、字段长度等进行验证。然后像用户名这样的验证已经存在，或者您需要与服务层中的其他对象进行交互？

视图模型可以只包含从 EF 返回的 POCO 类，还是应该使用 AutoMapper？

如果使用 AutoMapper 和 DTO，DTO 是 POCO 类的克隆吗？

你会映射到控制器、视图模型还是下面的服务层？

服务 对我来说，服务是联系存储库以从 EF 取回 POCO 对象的对象。这是我所有的业务逻辑所在。一旦服务将对象交回存储库以持久保存到 EF，它们就被视为有效对象。这是正确的吗？

存储库 它们中没有业务逻辑，它们仅用于在服务和 EF 之间传输对象。它是否正确？我在这里用通用存储库实现接口。那么您可以扩展通用存储库以满足特殊需求吗？

关于术语的问题 1) 业务对象是否等于领域对象？域对象应该包含多少逻辑？

2) 域模型是 EF 模型吗？我正在使用模型优先的方法。

3) 依赖注入 - 我应该使用它吗？我了解它是如何工作的，只是没有得到真正的好处。我在玩 Ninject。

我认为社区会从某种 wiki 中受益，该 wiki 包含代码示例的所有最佳实践。那里有类似的东西吗？那里的许多示例都非常简单，而且许多 Microsoft 示例即使声称使用这种模式也没有使用。

在此先感谢所有已经并将帮助我的人。

顺便说一句 - 我认为 *** 需要在“接受答案”复选框旁边有一个“给我买啤酒”按钮 :)

【参考方案1】：

视图模型是 DTO 吗？

可以认为是控制器和视图之间的一种数据传输对象。

它们应该只包含简单的属性，例如名称、地址线 1、地址城市等，还是应该包含复杂的属性、多个对象等。

理想的简单属性，但也可以聚合其他视图模型，但那里没有模型（例如：像 EF 模型）。

是视图模型中的验证。

有两种类型的验证逻辑：进入服务层的业务验证（例如，用户名已经存在）和进入视图模型的 UI 验证（例如：需要用户名）。

视图模型可以只包含从 EF 返回的 POCO 类，还是应该使用 AutoMapper？

视图模型中没有 EF。视图模型是具有简单属性和指向其他视图模型的其他复杂属性的 POCO 类。它们还可以包含一些方法，以便正确格式化将在这些模型所针对的特定视图上呈现的数据。

如果使用 AutoMapper 和 DTO，DTO 是 POCO 类的克隆吗？

不确定我是否理解这个问题。

你会映射到控制器、视图模型还是下面的服务层？

控制器。

对我来说，服务是与存储库联系以从 EF 取回 POCO 对象的对象。这是我所有的业务逻辑所在。一旦服务将对象交回存储库以持久保存到 EF，它们就被视为有效对象。这是正确的吗？

是的。

领域模型是 EF 模型吗？

如果您使用的是 EF 代码优先方法，则为是，否则为否（如果 EF 使用 EF 特定属性和类污染域）。

其中没有业务逻辑，它们只是用于在服务和 EF 之间传输对象。它是否正确？

是的。

我在这里使用通用存储库实现接口。那么您可以扩展通用存储库以满足特殊需求吗？

是的，但不要太花哨。通常存储库用于 CRUD 操作。它是应该包含业务逻辑的服务。

业务对象是否等于领域对象？

是的。

域对象应该包含多少逻辑？

这将取决于您正在处理的特定项目的领域逻辑数量，以及您可以从您或其他人从事的旧项目中重用的任何现有领域逻辑。

依赖注入 - 我应该使用它吗？

是的，绝对的。

我了解它的工作原理，只是没有得到真正的好处

它在应用程序的不同层之间提供了较弱的耦合，从而使它们更容易在其他项目中进行单元测试和重用。

我认为社区将从某种 wiki 中受益，该 wiki 包含所有带有代码示例的最佳实践。

我同意。

那里有类似的东西吗？

我怀疑。

顺便说一句 - 我认为 *** 需要在“接受答案”复选框旁边有一个“给我买啤酒”按钮

不能再同意了。

【讨论】：

arin - 如果使用 AutoMapper 和 DTO，DTO 是 POCO 类的克隆吗？我的意思是，如果说我有一个视图将显示客户的基本信息以及地址和订单的集合，我会假设视图模型将具有客户的基本属性，然后是地址的集合和命令。这些集合是 POCO 对象的属性，还是我需要在 MVC 应用程序中构建一个类来模仿 POCO 中的订单和地址类并在视图模型中使用它们？

@Darin - 使用模型优先方法从 EF 生成的 POCO 类是否与代码优先方法相同，或者也关闭代码优先方法？ POCO 课程非常简单。看看这里：striano.net/Customer.vb.txt，这是被污染了吗？

@Sam，如果您需要一个视图来显示客户的基本信息以及地址和订单的集合，您将构建一个包含基本属性和 AddressViewModel 的 CustomerViewModel 和一个OrderViewModel 将包含您希望向给定客户显示的关于他的地址和订单的属性，然后CustomerViewModel 可以有两个集合属性AddressViewModel 和OrderViewModel。

就域模型而言，就我个人而言，我在分析我的项目需求时手动定义它们，并且从不使用任何自动生成作为域模型的东西。如果您使用自动生成的东西，则意味着您的域逻辑基于此 something 恕我直言不是一件好事。由您来分析项目需求并定义域对象。在稍后阶段，您可以决定将模型映射到关系数据库或在互联网上购买第三方服务 API 或其他方式。

@Darin - 所以在客户订单和地址的情况下，每条记录都有一个视图模型？