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

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

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

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

但是,我也看到人们似乎只与BO合作,并且只在背景中使用DTO在哪里,用户看起来没有DTO.

这个体系结构与使用BO的结构相比有什么好处/下降？

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

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

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

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

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

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

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

希望这可以帮助.