3

在创建 n 层解决方案时，我不想公开我的业务对象，而是使用 DTO 来代替它。另一方面，我不想一直重复定义对象并编写复制代码。

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

然后我会从那些 DTO 中派生出我的业务对象，用我的业务逻辑扩展它们，处理 DTO 基类属性。这些对象也将是使用的 ORM (NHibernate) 中持久化的对象。

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

你觉得这种做法合理吗？

问候，

塞巴斯蒂安

4

3 回答 3

6

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

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

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

来自模式与实践：数据传输对象

另外，我自己没有使用过它，但您可能也想查看AutoMapper。

于 2009-11-03T17:56:55.747 回答
1

对我来说听起来很合理。在 Linq to SQL 中，业务对象是通过使用部分类从 DTO 派生的。

于 2009-11-03T15:53:20.000 回答
0

“然后我会从那些 DTO 派生出我的业务对象” 请记住，DTO 可能看起来与 BO 不同，它们可能包含来自 2 或 3 个 BO 的属性

于 2012-03-04T07:20:19.850 回答