POCO应该来自DTO还是更好？

Question

在创建n层解决方案时,我不想公开我的业务对象,而是使用DTO而不是这个.另一方面,我不想一直双重定义对象和编写复制代码.

现在我的想法是编写包含所有必要字段和属性的DTO,但没有逻辑(只有状态).

然后我将从这些DTO派生我的业务对象,使用我的业务逻辑扩展它们,处理DTO基类属性.这些对象也将是所使用的ORM中持久存在的对象(NHibernate).

使用这种方法,在服务器端,我可以处理业务对象并将它们直接传递给客户端(它们是派生的,因此可以向下转换).我不会被迫以这种方式暴露我的业务逻辑并节省大量代码.

你认为这种做法是明智的吗？

问候,

塞巴斯蒂安

Answer 1

您可能需要考虑以下事项:

"...,因为保持DTO不知道域对象使您能够在不同的上下文中重用DTO. 同样,您不希望域对象知道DTO,因为这可能意味着更改DTO需要更改代码在域逻辑中,这会导致维护噩梦.

最好的解决方案是使用Assembler模式,它从业务对象创建DTO,反之亦然.汇编程序是Mapper模式的一个专门实例,也在企业应用程序架构模式中提到...."

来自模式和实践:数据传输对象

另外,我自己没有使用它,但您也可以查看AutoMapper.