Nix*_*Nix 7 architecture entity-framework wcf-data-services
微软已经做了一项精明的工作,没有在SOA/Web开发的精彩世界中概述数据服务的实际位置.
所以我的问题是WCF数据服务是否可以通过外部客户端使用？有没有人听说有人在服务器端使用它们(即Web服务的数据库访问)？
简单场景使用BO业务对象的一般分层架构(括号表示层之间传递的内容)
(XML)WCF服务 - >(BO)业务逻辑 - >(BO)Dao - >实体框架
或者使用数据服务,DS BO是在数据服务中使用的建模业务实体.
(XML)WCF服务 - >(BO)业务逻辑 - >(BO)WCF数据服务 - >(DS BO)服务器
我不能看到后者的使用,除非很多情况下人们会通过您的数据服务层与服务层访问您的数据？
想到任何人,任何类型的参考文档都可以帮助它.
我正在寻找利弊,以帮助像我这样的其他人定义何时/何地使用数据服务.
这是我尝试概述我在这个主题上发现的所有内容。
数据服务的目的是通过 Web URI 公开某种类型的资源。所有数据均通过标准 HTTP 动词（GET、POST、PUT、DELETE）访问/更改。
DS 的标准响应（完全可配置）是 JSON/Atom。
开箱即用的数据服务风格旨在成为需要通过网络访问其数据的任何类型客户端的后端访问层。
数据服务支持添加额外的业务逻辑（通过服务操作/拦截器），但通常用于业务逻辑有限的情况。
总之，数据服务旨在面向客户，您公开您的数据，以便可以从其他机构通过网络访问它。虽然您可以强制数据服务适合后端服务器数据访问层，但只有在您能找到合理的理由时才应该这样做。数据服务带来了大量不必要的性能和编码开销。
我还没有找到任何资源（博客或文章）建议将它们用作服务器端应用程序上的 dao 层。
服务器端使用数据服务的案例：
1）更容易版本化数据服务。我可以发布实体模型的不同版本，而不影响使用它的每个人（有人可能会说，只需使用 ADO.NET 实体模型，您可以做同样的事情，只需多做一点工作）
2) 希望能够访问较低级别的数据。您允许后门访问您的数据库。在较高级别上，您将公开业务服务和后门数据访问服务。可能存在这样的情况：另一个域的数据模型中仅具有共享数据的子集，并且需要过滤模型中的某些内容。数据服务将允许您通过 uris 与 VIA 进行普遍对话。
资源