代码之家 › 专栏 › 技术社区 › Sebastian P.R. Gingter

POCO应该从DTO派生还是最好不要?

dto n-tier poco architecture c#

3

Sebastian P.R. Gingter · 技术社区 · 15 年前

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

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

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

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

你认为这种方法明智吗?

当做,

塞巴斯蒂安

3 回复 | 直到 12 年前

1

6

Chansik Im 15 年前

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

“…, 因为 让DTO不知道域对象使您能够重用不同上下文中的DTO。 同样,您不需要域要了解DTO的对象,因为那可能意味着 更改DTO 需要更改中的代码域逻辑 这将导致维护噩梦。

最好的解决方案是使用 汇编程序模式 从业务对象创建DTO,反之亦然。汇编程序是 映射器 模式也在中提到 企业应用程序体系结构模式 …”

从 Pattern and Practice: Data Transfer Object

另外,我自己也没有用过,但你可能想退房 AutoMapper 也。

2

1

Robert Harvey 15 年前

听起来很合理。在LinqToSQL中,业务对象是通过使用分部类从DTO派生的。

3

0

Mirza 12 年前

“那么我将从这些DTO中派生出我的业务对象”记住,DTO可能看起来与BO不同,它们可能包含来自2或3 BO的属性。