使用DTO和BO

Question

4

关于DTOs/BOs，我有一个疑问是何时传递/返回DTOs和何时传递/返回BOs。

我的直觉告诉我始终将NHibernate映射到DTOs而不是BOs，并始终传递/返回DTOs。然后，每当需要执行业务逻辑时，我就会将我的DTO转换为BO。

我这样做的方式是，我的BO将具有一个构造函数，该构造函数接受一个参数，即我的接口类型（定义所需字段/属性），该接口由我的DTO和BO实现作为唯一参数。

然后，我将能够通过在构造函数中传递DTO来创建我的BO（因为它们都实现相同的接口，它们都具有相同的属性），然后能够使用该BO执行业务逻辑。然后我还有一种将BO转换为DTO的方法。

但是，我也看到过人们似乎只使用BO，并且仅在后台使用DTO，对用户来说，看起来没有DTO。

与始终使用BO相比，这种架构的好处/弊端是什么？

我应该始终传递/返回DTO或BO，还是混合使用（似乎混合使用可能会让人困惑）？

- ryanzec

2

除非你把问题分成段落，否则我甚至不会阅读你的问题。 - John Saunders

3个回答

0

也许这个对你会有用： http://automapper.codeplex.com/。

- Felice Pollano

0

我知道这是一个相当古老的问题，但让我谈一谈关于此主题的我的想法。

无论使用何种MVC项目（即使是使用Entity Framework或NHibernate），我都使用POCO进行持久化，使用DTO/ViewModels进行中间操作，因为它们具有扁平化行为、更少的数据传输量，而且最重要的是，它们不以任何方式公开对象之间的关系。

我知道这听起来像是“万能药”，但至少对我来说一直有效。

（请原谅一些英文错误=)）

- cezarlamann

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Goblin · Accepted Answer

这取决于您希望实现什么目标。我可以告诉您我的做法 - 我在NHibernate中都映射了DTO和BO，但是DTO被映射为不可变的，这样我就不会无意中在没有使用BO的情况下更新数据库。

WebServices中所有可访问的查询都返回/接受DTO。

每当从DTO进行更新时，我都会进行UnitOfWork，在其中加载BO，从DTO更新属性，如果仍然有效，则再次保存。

在客户端上，每当客户端需要修改时，我从DTO创建BO（AutoMapper在这里绝对是一个有效的选择）。 BO具有一个类似于NHibernate的构造函数，它需要所有参数来创建它。

好处如下： *完全控制通过网络传输的数据量（DTO通常是扁平的，因此仅在第一次调用时发送关联类的ID）。 *我不必在两者之间拥有相同的属性 *我可以随意混合和匹配延迟加载 *我可以在DTO中利用标量查询和其他计算属性，而无需在BO中创建它们。 *我可以针对不同的场景为每个BO拥有多个不同的DTO。

所以，我想这可以算作混合和匹配，但是有明确的指导方针，我会在哪里做哪个 :-)。

希望这能帮到您。