c# - 使用 DTO 和 BO

Question

对我来说，关于 DTO/BO 的一个问题是关于何时传递/返回 DTO 以及何时传递/返回 BO。

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

我这样做的方式是，我的 BO 将有一个构造函数，该构造函数采用一个参数，该参数是我的接口(interface)类型(定义所需的字段/属性)，我的 DTO 和 BO 都将其作为唯一参数实现.

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

但是，我也看到人们似乎只使用 BO，并且只在后台使用 DTO，而对于用户来说，似乎没有 DTO。

与始终使用 BO 相比，此架构有哪些优点/缺点？

我应该始终传递/返回 DTO 或 BO 还是混合搭配(似乎混合搭配会让人感到困惑)？

Answer 1

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

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

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

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

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

所以，我想这符合混合和匹配的条件，但有明确的指导方针，我在哪里 :-)

希望这对您有所帮助。