多层应用中模型的命名约定答案

【问题标题】：Naming conventions for model in multi layer application多层应用中模型的命名约定
【发布时间】：2016-04-25 23:44:37
【问题描述】：

我是一名新开发人员，从未在大型企业公司工作过，所以我对多层应用程序中的命名约定有疑问。我有一个带有 EF 数据层的 WPF/MVVM 应用程序。我也想调整一下DDD原则。

所以，我会说三个同级别的模型。我在 MVVM 中有“模型”，在 EF 中有一个实体/dto（我不知道？），在 DDD 中有域模型/POCO。我必须创建所有这 3 个类来分离关注点（也许我可以将 MVVM 模型与 POCO 合并。我的意思是，POCO 是 MVVM 中的一种模型）。我应该如何命名它们？

假设我有 Person POCO。它应该是 EF 中的“Person”还是“PersonDto”？一般约定是什么？我遇到了两种方式都没有 Dto 后缀，所以我很困惑。

【问题讨论】：

标签： c# entity-framework mvvm domain-driven-design naming-conventions

【解决方案1】：

我通常为 DTO 和 ReadModels/ViewModels 添加后缀，而不是域对象。

没有硬性规定，这是个人（或团队）偏好的问题。有些人喜欢让命名空间来代替，但我发现它不太明确。

编辑：顺便说一句，我 not a huge fan 拥有一个单独的“持久性模型”（我是 not the only one）。在任何情况下，我都不会调用该层 DTO 中的对象。

【讨论】：

好文章。 Percistance 不可知论并不一定意味着单独的 DAO 用于 percistance
感谢这些文章。我会在一分钟内阅读它们。您不会将 EF 模型类称为 DTO。所以，只是简单的“人”？

【解决方案2】：

DTO：例如：PersonDto

DTO 是一个对象，它定义了数据将如何通过网络。

POCO：例如：Person

实体框架使您能够一起使用自定义数据类使用您的数据模型而不对数据进行任何修改自己上课。这意味着您可以使用“普通的”CLR 对象 (POCO)，例如现有的域对象，以及您的数据模型。这些 POCO 数据类（也称为持久性无知对象），映射到数据模型中定义的实体，支持大多数与实体相同的查询、插入、更新和删除行为由实体数据模型工具生成的类型。

希望对你有所帮助。

【讨论】：

谢谢，我理解对了吗？您是否建议我应该使用我的领域模型类作为我的数据层/实体框架的实体？
是的，你是对的。继续这样做吧。祝你好运！ :)
感谢您的提示，但我认为这不是一个好主意。您必须分离关注点，因此您不能将域模型用作持久性模型。阅读此blog.sapiensworks.com/post/2012/04/07/…
我正在为我的 SPA 应用程序使用 ASP.NET ZERO 框架。它具有 SOLID 架构和实施的领域驱动设计和完全多租户 (SaaS) 支持。在那个框架上，我们使用域模型作为我们的实体。你可以阅读它aspnetzero.com和aspnetboilerplate.com/Pages/Documents/Entities
@IvanBara 关于“持久性模型”，实际上存在争议。见enterprisecraftsmanship.com/2016/04/05/…

【解决方案3】：

我认为重要的是要记住一个人不是一个人。您想将它们分开的原因是因为它们可能会做非常不同的事情。

例如我可以有

人物数据库类/对象

（其中的一个子集）映射到学生域对象

然后前端为学生发送 AddressChange 更新。

当然，您也可以拥有 Person、PersonDTO 和 PersonDB，甚至还有 PersonVM（假设您在前端使用 javascript 类型）。要记住的是，您将它们分开是因为它们“完全不同”。如果你强迫它们总是完全相同，那么真的没有理由将它们分开。

【讨论】：

【解决方案4】：

几个月前，我遇到了以下文章，在为我的项目命名类/实体时，它确实对我有意义。

Naming Conventions - XAML made easy

希望对你也有帮助

【讨论】：

但是这篇文章没有提到命名模型。是关于 View 和 ViewModel 的，不是吗？
模型也是如此，在模型类名称中使用“模型”字样。

【解决方案5】：

我也想调整 DDD 原则。

那么一个绝对必要的条件是领域模型中使用的名称必须与您的领域专家的通用语言相匹配。

【讨论】：

EF 实体怎么样？它们应该以“Dto”为后缀吗？