c# - DTO（linq2sql）和类对象之间的混淆！

Question

我已经成功使用 linq2sql 和 linq DTO（由 linq2sql 创建的类）......

我很困惑，我有更新旧应用程序的任务，我可以看到我的 DTO 将按应有的方式使用.... 传输日期

我正在使用存储库模式，所以我通过 linq2sql dtos 将数据从存储库传递到服务......一旦我进入服务层（这基本上是我的业务逻辑），那么我需要传递类对象......

这些类对象基本上是 dtos 的镜像（或多或少） - 在某些地方有一些变化，但通常是相同的..

所以回到手头的问题！- 仅使用 dtos 将数据从存储库传输到服务层是这种好习惯吗……一旦进入服务层（业务逻辑），我应该将所有 dtos 映射到类对象计数器部件（当然使用自动映射器！！）

我的另一种选择是继续使用类对象之类的 DTOS，并将它们从方法传递到方法以及作为返回类型等，但我觉得这是不好的做法，我一直在想我应该应用哪种方法？

任何帮助都非常感谢

谢谢

score 5 · Accepted Answer

这是我的观点：在处理任何非平凡的应用程序时。使用 linq2Sql 对象作为域模型是一个非常糟糕的主意。我将 linq2Sql 视为 ORM，仅此而已。数据库（与 linq2Sql 有直接对应关系）是数据的规范化。类（在 OOAD 意义上）是行为（而不是数据）的规范化。

[这些类对象基本上是镜像]...

我在使用 linq2Sql 构建应用程序时遇到了这个问题。让我们现实一点......大多数业务线应用程序都是美化的 CRUD 应用程序。因此，应用程序的大部分实体将直接对应于数据库表并不是不可能的。 我不想直接绑定到生成的 DTO，但同时我不希望重复的类在我的应用程序中乱七八糟。

所以这是我的解决方案：
我“编程到一个界面”。

假设我有一个PersonDto（Dto 代表数据传输对象），其属性为FirstName, LastName, Age（直接与数据库列相关）。

我创建了一个IPerson接口并让我的 PersonD 来实现它。


  [Table(Name="Persons")]
  internal class PersonDto : IPerson
  {
      ....
  }

IPerson与Linq2Sql 类相反，我的存储库方法将接收和检索。


    IPerson somePerson = _repository.Get(someGuid);
    somePerson.FirstName = "SomeName";
    _repository.Save(somePerson);

这种方法对我来说非常有效。每当我觉得我需要偏离 DTO 时，我可以很容易地做到这一点，因为代表我的对象的接口而不是 DTO。

一些一般性建议：手动构建您的 DTO...我知道这听起来很疯狂，但您会发现它非常适合自上而下的测试驱动开发方法。您的 DTO (linq2Sql) 对象将非常轻巧，并且将对 .dbml 设计器之外的更改开放。

将 DTO 和 DataContext 保持在内部。没有理由公开公开您的 dto（假设您有存储库和域对象的公共接口）。这样做将强制在您的域模型和数据访问之间进行逻辑分离。

将所有数据访问层放在一个单独的项目中（再次强制执行这种分离）。

将您的接口声明放在一个单独的项目中（这将确保您不会遇到任何循环引用）。

希望这可以帮助...

score 3 · Accepted Answer

尽管我的意图略有不同，但我实际上对这个主题也有类似的问题。建议是使用 Linq2SQL 类作为域对象，并像其他人提到的那样利用部分类。我主要关心的是这些对象的形状（即属性名称），以及类成员的可访问性（例如，私有与受保护）。

对象的形状甚至可访问性都可以通过使用 t4 模板来解决，其中 Damien Guard 将 T4 模板放在一起，以允许您控制 Linq2Sql 将为您生成的类的形状。这可以在这里看到Linq2SQL 的 T4 模板。

这是我要研究的方法，看看它是否能解决我的担忧。此外，如果您的服务层可以接受方法参数的接口，您还可以通过 Linq2SQL DTO 周围的接口包装器来控制服务层可以访问的内容。

希望这可以帮助。

score 2 · Accepted Answer

这是我见过的关于该主题的最佳讨论之一：

最后，耦合和内聚的决定是视情况而定的，你必须决定什么最适合你的情况。

当您的应用程序超出 LinqToSql 时，抽出 LinqToSql 并在其位置插入另一个 ORM 会有多容易？这是你必须认真考虑的事情。

一般来说，尽量减少您的业务层对 LinqToSql 的了解。LinqToSql 应该从你的 UI 层完全隐藏（你的业务层构成了这个屏蔽的很大一部分）。使用 LinqToSql 很容易走上错误的架构路径，而事后又很难回到正确的路径上。

score 0 · Accepted Answer

linq2sql 设计器生成的类是部分类，因此您可以扩展这些类并将您的业务逻辑直接放入其中。这个想法是 linq 用于持久化/重建这些实体，因此您可以避免您正在谈论的那种映射。

4 回答 4