【发布时间】：2010-11-30 21:29:46
【问题描述】：
使用 odata 服务，我们可以在不使用 dto 的情况下从客户端进行查询。如果我使用 odata svc，我真的需要 dto 层吗？如果我不使用 dto，有什么缺点和优点。在我们用于查询机制的旧系统中，有许多返回 dto 集合的查询服务方法。但是 odata 服务让我很困惑……看起来像；服务器的责任转移到客户端。对于事务脚本，同样的混乱还在继续。我很好奇你的想法。
【问题讨论】：
【发布时间】：2010-11-30 21:29:46
【问题描述】：
当您在服务器端时 - 对 oData 来说唯一重要的是 EDM 模型或 POCO 模型。因此，当您生成 EDMX 文件时，您始终可以将它们视为您的业务对象或模型层，然后将其泵入这些名称空间。因此，在某种程度上，您没有在其中应用业务逻辑。
但在客户端，您始终可以集中 oData 方法调用。由于它们支持回调，因此您始终可以让视图模型调用存储库并将回调传回。这样，您就不会因大量的 odata 查询调用而使您的视图模型膨胀。我说的是某种存储库模式。
希望这能给你一个方向。
问候 :)
【讨论】：
-
你说，存储库在客户端，模型在服务器端。但这不是很奇怪吗？我们称为“域”的东西，由存储库和模型组成。但是为什么我需要将它们分成两个不同的物理层？
-
据我所知 - 存储库只是一种模式。没有标签表明这需要在服务器端或客户端。我的意思是——使用 WCF 数据服务架构——你将只有 2 个文件：1 个文件是 .EDMX 及其对应的 .CS 文件，所有 EF 模型都驻留，2 个文件在其中定义了 WCF Dara 服务。因此，这就是您在服务器端公开 oData 所需的全部内容。关于客户端，我想说的是——一种在一个地方控制 oData 查询调用的架构。您可以将其命名为存储库，甚至可以命名为普通类 :)