c# - 使用 DTO 而不是在公共(public)程序集中共享对实体的引用是否有好处？

Question

我正试图为一个让我抓狂了很长时间的问题找到一个明确的最终答案。

通常表示 BLL 应包含业务逻辑和业务对象 (BO)，并具有对 DAL 的引用。另一方面，DAL 不能引用 BLL，因此它不能接受 BO 作为参数，或返回 BO 作为返回值。

这个问题最传统的答案是:

a) 接受简单参数，返回(最好是Typed)DataSets和DataTables返回数据: 命名空间 DAL { 公共(public)课联系方式 公共(public)数据表 GetContacts(){...} 公共(public) UpdateContacts(DataTable 联系人){...}

b) 第二个最推荐的解决方案是定义临时的、可序列化的数据传输对象 (DTO)(有时称为值对象 (VO))，它们只有字段和属性，没有方法，仅用于简单地传输数据数据备份到 BLL 层，在那里用于填充新的 BO，此时它们将被丢弃。

c) 使用通用的第三个程序集(例如称为 Entities.dll)，它定义了 BO，并被所有 3 层引用:UI、BLL 和 DAL。

选项 a) 的实现工作量最少(无需构建另一个程序集)，因此经常被提出，但 DataTables 有额外的布线，不需要只是为了简单的操作。

但目前还不清楚 b) 或 c) 哪个更好...

我看到 b) 有时会提供，而 c) 几乎从不提供，尽管 c) 似乎是两者中最简单的。

我错过了什么？为什么 c) 很少提供，即使它在逻辑上看起来是最简单的，为什么 a) 在它显然不适合所有场景(例如返回单个对象)时提供？

谢谢!

Answer 1

好吧，我几乎看不到 (b) 在实践中使用。大多数时候我都使用 (c) 中描述的方法(其他时候我什至不区分 BLL/DAL 或根本没有域模型)。毕竟，业务和数据组件通常在物理上位于同一位置，因此由这两者共享 BO 是很简单的。事实上，Hibernate、Entity Framework、Linq2Sql 等框架实际上鼓励 (c) 允许对复杂域模型执行 ORM。

不过，DTO 通常用于将数据从 BLL 传递到 UI，尤其是。当 UI 和 BLL 部署在不同的服务器中时。在这种情况下，UI 可能需要域模型的简化 View ，以减少跨进程往返并最大限度地减少更改的影响(当域模型更改时)。