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