多层应用程序中模型的命名约定



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

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

假设我有个人 POCO。在 EF 中应该是"Person"还是"PersonDto"?一般惯例是什么?我已经遇到了两种方式 w/wo Dto 后缀,所以我很困惑。

我通常给DTO和ReadModels/ViewModels后缀,但不给域对象加后缀。

没有硬性规定,这是个人(或团队)偏好的问题。有些人喜欢让命名空间代替,但我发现它不那么明确。

编辑:顺便说一句,我不是拥有单独的"持久性模型"的忠实粉丝(而且我不是唯一一个)。无论如何,我不会将该层中的对象称为DTO

DTO : 例如: PersonDto

DTO 是一个对象,用于定义如何通过 网络。

POCO : 例如: Person

实体框架使您能够同时使用自定义数据类 使用您的数据模型,而无需对数据进行任何修改 类本身。这意味着您可以使用"普通旧"CLR 对象 (POCO),例如具有数据模型的现有域对象。 这些 POCO 数据类(也称为忽略持久性的对象), 映射到数据模型中定义的实体,支持 大多数查询、插入、更新和删除行为与实体相同 由实体数据模型工具生成的类型。

希望这对您有所帮助。

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

例如,我可以有

人员数据库类/对象

映射到学生域对象的子集

然后前端为学生发送地址更改更新。

当然,你也可以有Person,PersonDTO和PersonDB,甚至一个PersonVM(假设你在前端使用javascript类型)。要记住的是,您将它们分开,因为它们"完全不同"。如果您强迫它们始终完全相同,那么真的没有理由将它们分开。

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

命名约定 - XAML 变得简单

我希望它也会帮助你

我还想调整 DDD 原则。

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

最新更新