关于DTO / BO的一个问题是关于何时通过/返回DTO以及何时通过/返回BO。
我的直觉反应告诉我总是将NHibernate映射到DTO而不是BO，并且总是传递/返回DTO。然后每当我需要执行业务逻辑时，我都会将我的DTO转换为BO。
我这样做的方法是我的BO会有一个构造函数，它接受一个参数，该参数是我的DTO和BO实现的唯一参数的接口类型（定义了必需的字段/属性） 。
然后我可以通过在构造函数中传递DTO来创建我的BO（因为两者都实现了相同的接口，它们都具有相同的属性）然后能够使用该BO执行我的业务逻辑。然后我还可以将BO转换为DTO。
但是，我也看到人们似乎只与BO合作，并且只在背景中使用DTO，在用户的背景中，看起来没有DTO。
这种架构与使用BO的结果有什么好处/垮台？
我是不是总是传递/返回DTO或BOs或混合搭配（看起来混合和匹配可能会让人感到困惑）？
答案 0 :(得分：2)
这取决于你想要达到的目标。我可以告诉你我自己做了什么 - 我在NHibernate中映射了DTO和BO，但是DTO被映射为不可变的，所以我不会在不使用BO的情况下无意中更新数据库。
WebServices中可访问的所有查询都返回/接受DTO。
每当从DTO更新时，我都会执行UnitOfWork，我在其中加载BO，从DTO更新属性并在它仍然有效时再次保存。
在客户端，每当客户端需要修改它时，我都会从DTO创建BO（AutoMapper绝对是一个有效的选择）。 BO有一个ctor，它接受所有创建它的参数，类似于NHibernate所做的。
好处是： *完全控制通过网络传输的数据量（DTO通常是扁平化的，因此在第一次调用时只发送关联类的Id）。 *我不必在两者中都具有相同的属性 *我可以根据需要混合和匹配延迟加载 *我可以在DTO中使用标量查询和其他计算属性，而无需在BO中创建它们。 *对于不同的场景，我可以为每个BO设置几个不同的DTO。
所以，我想这可以作为混合和匹配，但我有明确的指导方针： - ）
希望这有帮助。
答案 1 :(得分：0)
也许你会发现这个： http://automapper.codeplex.com/ 也很有用。
答案 2 :(得分：0)
我知道这是一个很老的问题，但是让我就这个问题给出“十分钱”。
当使用任何MVC项目（甚至使用Entity Framework或NHibernate）时，我使用POCO进行持久化，使用DTO / ViewModel进行中间工作，因为行为扁平化，线上数据较少，而且最后（但并非最不重要） ），它们不会以任何方式暴露对象之间的关系。
我知道这可能听起来像是“银弹”，但至少它对我有用了一段时间。
（原谅一些英语错误=））