具有数据存储库的服务层[关闭]

Question

谁能解释一下？ 我正在尝试将我的 wpf 应用程序 mvvm 转换为不同的层（读取 ddd）。我有一些小困惑

• 表示层（WPF、WEB、API）（好的……我知道）
• 实体模型（我知道是代表数据库表的类，例如 来自实体框架的客户 {id,name,surname,phone}

但以下让我感到困惑

• 域模型（是代表sql表列的类吗？例如 客户 {Id,Name,Surname,phone} 或对我有意义的类 应用程序，例如客户 {ID,FullName,Balance}
• 领域模型在哪里？在哪一层（单独的dll？，在服务中 层 ？或在数据存储库 dll 中）
• DTO（Data Transfered object）和领域模型一样吗？
• 服务层（是单独的 dll 吗？）
• 业务层（很多时候我看到业务层这个词，有些 将其称为服务层）它实际上是什么？是一样的吗？是吗 不同的班级？拥有自己的不同 dll（层） 服务层之外的责任？
• 数据存储库（问题是，服务层或业务层是否应该在存储库所在的同一层中实现）

通过以上所有内容，我制作了示例应用程序，试图了解每个应用程序的去向。

我遵循的步骤

1. 我已成功了解数据存储库。一个简单的界面 使用 CRUD 和/或复杂查询
2. 我创建了一个IService，它实现并继承自存储库
3. 现在在 wpf 中我必须引用服务 dll，但 wpf 不仅需要服务 dll，还需要存储库 dll，因为服务层正在使用它。

我的问题是。正常吗？服务不应该是独立的吗？

服务层应该使用它自己的模型吗？并将数据存储库模型转换为服务模型？因此 wpf 不需要参考存储库吗？ （但如果是这样的话......不是重复工作吗？）

Answer 1

领域模型

这取决于您要实现哪种模式：富域模型或贫血。

一些参考：

• DDD vs Anemic domain models
• Anemic domain model
• Rich vs anemic domain model

两个字：

• 富域模型 - 当业务逻辑封装在您的业务对象（模型）中时，它就是一个模型。
• 贫血领域模型 - 它是一个模型，当业务逻辑在服务层实现时。

如果你谈论服务，它不是纯粹的 DDD，它是贫乏的。 Fowler 说贫血是一种反模式，但它经常被使用。富域模型的主要问题，你需要大量的经验来实现它的正确方法。
我认为在您的情况下，您可以将实体用作域对象。

领域模型在哪里？

如果您尝试实现领域模型，则需要您的解决方案的组织结构。
通常它包含下一个项目：

*.Domain - 用于域对象
*.Application - 用于业务逻辑，如果我们谈论贫血模型
*.Dto 或 *.Contract - 用于 dto 或其他可在外部使用的对象您的应用程序范围（用于服务交互、dto 等）
*.Persistence - 用于数据层

Dto(Contract) 被放置在另一个项目中，以防重复使用在它们实现的项目。

其中 * 是您的项目名称。

DTO

Dto 取决于您的需要。 我建议为每个目的声明 dto，但如果您不想要，您仍然可以返回域对象（但有些人会说，这是不好的做法）。
正如我之前所说，您可以将 dto 放在 *.Dto 或 *.Contract 项目中

服务层和业务层

在您的*.Application 处实施

数据存储库

通常您更喜欢在*.Domain 或*.Application 声明Data Repository 接口，在*.Persistence 实现实现。它允许您使用接口而不关心实现。

正常吗？服务不应该是独立的吗？

最佳实践是服务仅取决于您的 *.Domain 程序集。

服务层应该使用它自己的模型吗？并将数据存储库模型转换为服务模型？因此 wpf 不需要参考存储库吗？ （但如果是这样的话......不是重复工作吗？）

您的服务应该使用域模型，并在需要时返回 dto。 ddd 的一般思想之一，即您对所有操作都有共同的模型。因此，如果您可以从存储库中返回您的域模型，那就太好了。