“保存”方法是不是属于业务域实体?

Posted

技术标签:

【中文标题】“保存”方法是不是属于业务域实体?【英文标题】:Does "Save" method belong to the Business Domain Entity?“保存”方法是否属于业务域实体? 【发布时间】:2012-07-21 18:12:39 【问题描述】:

我没有使用任何 ORM。所以我在争论“保存”方法是否真的属于业务领域实体,还是应该在某些服务中抽象出来,然后交给业务领域实体进行保存?

例如

class Employee

    string Name;
    DateTime Birth;

    GetAge()
    

    

    Save()
    
               


class Employee
   
    string Name;
    DateTime Birth;

    GetAge()
    

    




SomePersistenceService

    Save(Employee emp)
        
        

【问题讨论】:

【参考方案1】:

没有单一的最佳解决方案,您所说的问题是在存储库和活动记录模式之间进行选择。

通常,Repository 更适合单元测试,因为 Repository 接口易于模拟,而且 Repository 模式使用高内聚和单一职责原则(从 OOP 的角度来看,您的业务实体将包含用于保存的代码可能看起来很奇怪自身到数据库,通过网络传输自身,或导出到某些 XML 等)

Active Record 可能会在 RAD 开发中提供更快的速度,而 Spring Roo 等一些工具最初设计时仅支持 Active Record,据我所知,最近才添加了 Repository 支持。 AFAIK Ruby On Rails 使用 Active Record,以及其他一些很棒的工具。

对于领域驱动设计,您应该按照 Jeroen 的建议使用 Repository,因为 Repository 是基本的 DDD 模式(它是 DAO 模式的以领域为中心的版本),但您应该检查您的工具是否直接支持这两种模式.

【讨论】:

【参考方案2】:

由于此问题被标记为“领域驱动设计”,因此您需要一个存储库来为您解决问题。


只需将 SomePersistenceService 重命名为 EmployeeRepository。所以你的第二个选择是正确的。 “抽象在某些服务中将被移交的业务领域实体”在领域驱动设计中称为repository

存储库是一种将数据存储区伪装成集合的方式。所以它有像AddRemove这样的方法,而不是SaveDelete

【讨论】:

@@Jeroen,如果能通过修改我的示例来展示一个示例,我将不胜感激。

以上是关于“保存”方法是不是属于业务域实体?的主要内容,如果未能解决你的问题,请参考以下文章

具有业务对象、DTO 和实体/域对象的数据转换模式

不禁将域实体视为浪费。为啥?

三层架构

需要的意见:连接或断开域模型中的实体更好吗?

如何解决跨域问题

canvas2html 遇到的跨域问题