Dto/TransactionScripts 和 Odata 服务
通过odata服务，我们可以从客户端进行查询，而无需使用dto。如果我使用 odata svc，我真的需要 dto 层吗？如果我不使用 dto，有什么缺点和优点。在我们旧的查询机制系统中，有许多返回 dto 集合的查询服务方法。但odata服务让我困惑......看起来像；服务器的责任转移到客户端。对于交易脚本来说，同样的混乱也在发生。我很好奇你的想法。
With an odata service, we can query from the clientside without using dto. Do i really need dto layer if i use odata svc? What are the cons and pros if i don't use dto. In our old system for querying mechanism there are many query service-methods that returns dto collection. But odata services confuses my mind... It seems like; the responsibility of server moves to the client. The same confusion goes on, for transaction scripts. I'm curios about your thoughts.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
当您在服务器端时，对 oData 来说唯一重要的是 EDM 模型或 POCO 模型。因此，当您生成 EDMX 文件时，您始终可以将它们视为您的业务对象或模型层，然后将其泵入这些命名空间。因此，在某种程度上，您没有在其中应用任何业务逻辑。
但在客户端，您始终可以集中 oData 方法调用。由于它们支持回调，因此您始终可以让视图模型调用存储库并传回回调。通过这种方式，您就不会因大量的 odata 查询调用而使视图模型膨胀。我正在谈论的是某种存储库模式。
希望这能给你一个方向。
问候 ：）
When you are on the server side - the only thing that matters for oData is either a EDM model or POCO models. So when you genrate a EDMX file you can always considered those to be your business object or model layer and pump then in to those namespaces. So in a way there is no business logic that you are applying in there.
But on the client side you can always centralize the oData method invocation. Since they support callbacks you can always have a view model call up a repository and pass the call back. In this way you dont bloat your view model with extensive odata query invocation. Sort of repositroy pattern is what i am talking about.
Hope this gives you a direction.
regards :)