使用DTO和BO

关于DTO / BO的一个问题是关于何时通过/返回DTO以及何时通过/返回BO。

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

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

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

但是，我还看到人们似乎只与BO一起工作，并且只在后台使用DTO进行用户，看起来没有DTO。

这种架构与使用BO相比有什么好处/下降？

我应该总是传递/返回DTO或BOs或混合和匹配（似乎混合和匹配可能会让人困惑）？

Answer 1

这取决于你想要达到的目标。 我可以告诉你我自己做了什么 – 我在NHibernate中映射了DTO和BO，但是DTO被映射为不可变的，因此我不会在不使用BO的情况下无意中更新数据库。

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

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

在客户端，每当客户端需要修改它时，我都会从DTO创建BO（AutoMapper绝对是一个有效的选择）。 BO有一个ctor，它接受所有参数来创建它，类似于NHibernate所做的。

好处是：*对通过线路传输的数据量的完全控制（DTO通常是扁平化的，因此在第一次调用中仅发送关联类的Id）。 *我不必在两者中都具有相同的属性*我可以根据需要混合和匹配延迟加载*我可以在DTO中使用标量查询和其他计算属性而无需在BO中创建它们。 *对于不同的场景，每个BO我可以有几个不同的DTO。

所以，我想这可以作为混合和匹配，但我有明确的指导方针:-)

希望这可以帮助。

Answer 2

也许你会发现这个： http ： //automapper.codeplex.com/也很有用。

Answer 3

我知道这是一个很老的问题，但让我就这个问题给出“十分钱”。

当使用任何MVC项目（甚至使用Entity Framework或NHibernate）时，我使用POCO进行持久化，使用DTO / ViewModel进行中间工作，因为行为扁平，线上数据较少，最后（但并非最不重要），它们不要以任何方式暴露对象之间的关系。

我知道这听起来像是一个“银弹”，但至少它对我来说有一段时间了。

（原谅一些英语错误=））