存储库可以有DTO吗?

时间:2009-09-16 12:44:49

标签: repository-pattern

我有一个DTO和实体,例如PersonDTO和Person。 我使用DDD创建了一个aaplication PersionApplciation,它将DTO作为输入并在内部调用PersonService。 在PersonService中,我使用PersonFactory获取Person的实例(仅从DTO填充并将值设置为Person实体)。获取Person的实例后,我调用personRepository的add方法将记录保存到DB中。 再次在查询方法中,我必须将DTO返回给personApplication。为此我使用personService中的方法我调用PersonRepository,它加载Person实体并填充personDTO并将personDTO返回给personService,personService将DTO返回给personApplication。

我的做法是对还是错?

1 个答案:

答案 0 :(得分:1)

设计很少100%正确或100%错误。最好开始询问有关您的设计的问题,挑战您的决定并强迫自己通过逻辑辩护来推理。

例如,我觉得PersonDTO是多余的。为什么不能只将Person实体用于这两个操作?它几乎肯定拥有与DTO对象相同的所有数据字段。现在当你更改Person时,你将不得不更新两个类。

DDD还建议工厂和存储库逻辑的最佳位置在Entity类本身内。例如,您的Person对象可以有一个名为save()的实例方法,该方法会保留对数据库的任何更改。反对这种情况的论据曾经是持久性通常是很多工作(想想所有的ORM)所以它应该(理所当然地)被分离出来。现代持久性API(如JPA,JCR和Hibernate,NHibernate,TopLink等框架)使实体的持久性成为一个单行。同样,您可以将Factory作为静态(类)工厂方法,将其带入Person Entity。这些更改是可选的,但想法是Person应该知道如何构建和持久化。

最后,拥有服务层有点争议。你有一些像马丁福勒这样的OOD伟人,他们从不使用服务层(这个逻辑属于域名),但同时也会捍卫那些选择的人。我发现服务层可用作事务层和API导出层(想想将服务API打开到RMI或Web服务)。