在服务模型中重用存储库模型？答案

【问题标题】：Reusing Repository Model in Service Model?在服务模型中重用存储库模型？
【发布时间】：2020-01-14 02:40:52
【问题描述】：

我正在实现一个 Web Api，目前正在将服务模型与域模型分开。但是我想知道在控制器模型中重用存储库模型是否是不好的做法？

例如：

存储库模型

PersonRepositoryModel {
    public string Name { get; set; }
}

PersonAddressRepositoryModel {
    public string StreetName { get; set; }
}

服务模式

PersonServiceModel {
    public string Name { get; set; }
    public List<PersonAddressRepositoryModel> { get; set; } // <-- Is this bad? Should I create a PersonAddressServiceModel?

}

我的问题是，即使属性完全相同，创建服务模型是否总是好的做法？示例是上面 PersonAddressRepositoryModel 的用法，它不会有任何不同的属性。

如果我想在我的存储库中使用它，我需要创建一个 RepositoryModel 的实例，如下所示：

IPersonRepository {
   public long AddNewPersonAddress(PersonAddressRepositoryModel newAddress);
}

【问题讨论】：

您使用过哪种架构类型？我猜Onion被使用了。
是的，我使用的是洋葱架构。

标签： .net design-patterns asp.net-core-webapi

【解决方案1】：

是的，将领域模型与服务模型分开始终是一个好习惯。构建 web api 的第一条规则是：永远不要破坏已发布的 api！

为了永远不会随着时间的推移而违背这一承诺，必须将两层明确分开。

随着时间的推移，您的领域模型通常会发生变化，如果您有一个单独的服务模型，您可以在后台处理由变化引起的不匹配，而不是破坏 api。

这是您在开始时付出的一点额外努力，但稍后您会为这笔费用感到高兴。

【讨论】：

谢谢！我现在看到了，从长远来看，它会更有益，即使这些属性似乎存在“重复”。请问您如何在服务和域模型中命名您的模型？区分它们？
@Water 我通常将域模型中的类命名为它们所代表的实体：例如“Customer”，我将服务层中的类命名为实体名称和后缀“Dto”：“CustomerDto”。 Dto 喜欢数据传输对象。

【解决方案2】：

看看这个link（Microsoft 示例项目之一）。在域层中有一个 Order 具有一些属性。如果您检查属性，您可以看到它们的 setters 是私有的，并且它们只能在此类中访问。这种设计的主要原因是控制这个类的业务。它可以帮助我们进行维护。
因此，要创建Order 的实例并将其存储在数据库中，您需要具有相同属性的不同DTO 或Model。

【讨论】：