使用 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 或 BO 还是混合匹配（看起来混合和匹配可能会让人困惑）？

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

Web 服务中可访问的所有查询都会返回/接受 DTO。

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

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

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

所以，我想这符合混合和匹配的条件，但有明确的指导方针，我应该做什么:-)

希望这可以帮助。