在创建n层解决方案时，我不想公开我的业务对象，而是使用DTO而不是这个。另一方面，我不想一直双重定义对象并编写复制代码。
现在我的想法是编写包含所有必要字段和属性的DTO，但没有逻辑（只有状态）。
然后，我将从这些DTO派生我的业务对象，使用我的业务逻辑扩展它们，处理DTO基类属性。这些对象也将是使用的ORM中持久存在的对象（NHibernate）。
使用这种方法，在服务器端，我可以处理业务对象并将它们直接传递给客户端（它们是派生的，因此可以向下转换）。我不会被迫以这种方式公开我的业务逻辑并节省大量代码。
你认为这种做法是否明智？
此致
塞巴斯蒂安
答案 0 :(得分：6)
您可能需要考虑以下事项：
” ...， 因为让DTO不知道 域对象使您可以重用 DTO在不同的背景下。 同样，您不需要域名 对象了解DTO因为 这可能意味着改变DTO 需要更改代码 域逻辑，这将导致一个 维护噩梦。
最佳解决方案是使用汇编程序模式，它可以从业务对象创建DTO，反之亦然。 Assembler是企业应用程序架构模式中提到的 Mapper 模式的专用实例。“
来自Pattern and Practice: Data Transfer Object
另外，我自己没有使用它，但您也可以查看AutoMapper。
答案 1 :(得分：1)
对我来说很合理。在Linq to SQL中，业务对象是通过使用部分类从DTO派生的。
答案 2 :(得分：0)
“然后我会从那些DTO派生我的业务对象”请记住，DTO可能看起来与BO不同，它们可能包含来自2或3 BO的属性