Dto/TransactionScript和Odata服务

使用odata服务，我们可以从客户端进行查询，而不必使用dto。如果我使用odata svc，我真的需要dto层吗？如果我不使用dto，有什么利弊。在我们以前的查询机制系统中，有许多查询服务方法返回dto集合。但odata服务让我困惑。。。好像,；服务器的责任转移到客户端。对于事务脚本，同样的困惑还在继续。我对你的想法很好奇。

当你在服务器端时，对oData来说唯一重要的是EDM模型或POCO模型。因此，当您生成一个EDMX文件时，您可以始终将其视为您的业务对象或模型层，然后输入到这些名称空间中。因此，在某种程度上，这里没有您正在应用的业务逻辑

但是在客户端，您可以始终集中oData方法调用。因为它们支持回调，所以您总是可以让视图模型调用存储库并传递回调。这样，您就不会因为大量odata查询调用而膨胀视图模型。我说的是一种安置模式

希望这能给你一个方向

---

注意：

您说，存储库在客户端，模型在服务器端。但这不是很奇怪吗？我们称之为域的东西，由存储库和模型组成。但为什么我需要将它们分为两个不同的物理层呢？据我所知，存储库只是一种模式。不需要在服务器端或客户端进行标记。我想说的是，使用WCF数据服务体系结构，您将有2个文件：1个文件是.EDMX及其对应的.CS文件，所有EF模型都位于其中，2个文件是定义WCF Dara服务的文件。这就是服务器端公开oData所需的全部内容。关于客户端，我想说的是一个在一个地方控制oData查询调用的体系结构。您可以将其命名为repository，甚至是普通类：