WCF 数据服务实施策略
Microsoft 做得很精明，没有概述数据服务在 SOA/Web 开发的奇妙世界中的实际位置。
所以我的问题是 WCF 数据服务是否设计为通过外部客户端使用？有谁听说过有人在服务器端使用它们（即 Web 服务的数据库访问）？
简单场景使用 BO 业务对象的通用分层架构（括号表示层之间传递的内容）
(XML) WCF 服务 -> (BO)业务逻辑-> (BO)道->实体框架
或使用数据服务，DS BO 是对数据服务中使用的业务实体进行建模的地方。
(XML) WCF 服务 ->(BO) 业务逻辑 -> (BO) WCF 数据服务 -> (DS BO)服务器
我看不到后者的用途，除非在很多情况下人们会通过数据服务层与服务层访问您的数据？
认为任何人、任何类型的参考文档都会有帮助。
我正在寻找利弊来帮助像我这样的其他人定义何时/何地使用数据服务。
Microsoft has done a savvy job of not outlining the actual place for data services in the wonderful world of SOA/Web dev.
So my question is are WCF Data Services designed to be used via external clients? Has anyone ever heard of someone using them on the server side (i.e. data base access for web service)?
Simple scenario a general layered architecture using BO business objects (parenthesis indicate what is being passed between layers)
(XML) WCF Service -> (BO)Business Logic -> (BO) Dao -> Entity Framework
or using data services it would be where DS BO are modeled business entities to be used in data service.
(XML) WCF Service ->(BO) Business Logic -> (BO) WCF Data Service -> (DS BO)Server
I can't see a use for the later, unless there are going to be a lot of cases people would be accessing your data via your Data Service Layer vs the Service layer?
Thoughts anyone, any type of reference doc that would help back it would be useful.
I am looking for pros/cons to help other people out there like me define when/where to use data services.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
不要做第二个。
WCF 数据服务接口基于 Atom Pub，而 Atom Pub 基于面向客户端的 REST。
这是一个关键原因。您无法通过 WCF 数据服务接口执行两阶段提交事务，我希望 WCF 团队永远不要尝试启用它。
WCF 数据服务旨在将数据公开给远程客户端，而不是作为体系结构中的一层。
Do not do the second.
The WCF Data Services interface is based on Atom Pub, which is based on REST which is intended to be client facing.
Here is one key reason. You cannot do two-phase-commit transactions over a WCF Data Service interface and I hope the WCF team never try to enable it.
WCF Data Services is about exposing data to a remote client, not as a layer in an architecture.
这是我尝试概述我在这个主题上发现的所有内容。
数据服务的目的是通过 Web URI 公开某种类型的资源。所有数据均通过标准 HTTP 动词（GET、POST、PUT、DELETE）访问/更改。
DS 的标准响应（完全可配置）是 JSON/Atom。
开箱即用的数据服务风格旨在成为需要通过网络访问其数据的任何类型客户端的后端访问层。
数据服务支持添加额外的业务逻辑（通过服务操作/拦截器），但通常用于业务逻辑有限的情况。
总之，数据服务旨在面向客户，您公开您的数据，以便可以从其他机构通过网络访问它。虽然您可以强制数据服务适合后端服务器数据访问层，但只有在您能找到合理的理由时才应该这样做。数据服务带来了大量不必要的性能和编码开销。
我还没有发现任何资源（博客或文章）建议将它们用作服务器端应用程序上的 dao 层。
在服务器端使用数据服务的案例：
1）更容易对数据服务进行版本控制。我可以发布实体模型的不同版本，而不影响使用它的每个人（有人可能会说，只需使用 ADO.NET 实体模型，您可以做同样的事情，但需要做更多的工作）
2）希望能够以较低的速度访问数据等级。您允许后门访问您的数据库。在较高级别上，您将公开业务服务和后门数据访问服务。可能存在这样的情况：另一个域的数据模型中仅具有共享数据的子集，并且需要过滤模型中的某些内容。数据服务将允许您通过 uris 与 VIA 进行普遍对话。
资源
使用 Microsoft ADO.NET 数据服务的白皮书
ADO.NET 数据服务概述
简化我们的 n 层开发平台：将 3 件事变成 1 件事
网络数据服务
Here is my attempt to outline everything i have found on this subject.
The purpose of Data Services are to expose some type of resource via a web URI. All data is access/changed via standard HTTP verbs (GET, POST, PUT, DELETE).
The standard response for a DS (completely configurable) are JSON/Atom.
The out of the box style of data services are designed to be the back end access layer for any type of client that needs to access its data across the web.
Data Services support adding additional business logic(through service operations/interceptors) but generally are used in cases where business logic is limited.
In summary Data Services are designed to be client facing, you are exposing your data so it can be accessed over the web from some other body. While you could force data services to fit into a back-end server data access layer, you should only do so if you can find a justifiable reason to do so. With data services come a lot of unnecessary overhead performance and coding.
I have not found any resources(blogs or articles) suggesting that these be used as a dao layer on server side applications.
Cases for using Data Service on the server side:
1) Easier to version data services. I can release varying versions of an entity model without affecting everyone that uses it (one could argue that you could do the same with a little more work just using a ADO.NET Entity model)
2) Want the ability to access data at a lower level. You are allowing a back door access into your database. In a high level you are exposing a Business Service, and a Back Door Data Accesses Service. There could exist a case where a another domain only has a subset of shared data in its data model and needs to filter on something that is in your model. A data service would allow you to talk VIA universally via uris.
Resources
White Paper Using Microsoft ADO.NET Data Services
ADO.NET Data Services Overview
Simplifying our n-tier development platform: making 3 things 1 thing
Data Services for the Web
在数据服务上设置数据访问层无异于自杀。 WCF 数据服务适用于远程客户端。就是这样。
Setting up your data access layer on data services is a suicide. WCF data services are for remote clients. That's it.
请记住，术语“客户端”具有广泛的含义，并且可以具体包括后端系统，因此从这个意义上来说，简短的答案是肯定的。我还没有听说有人在服务器端使用它们，但没有理由不这样做； RSS 用于在系统之间联合数据，WCF 数据服务将是实现此目的的另一种方式。
也许您是从以技术为中心的角度来看待这个问题，但实际上您需要更全面地思考？ WCF 数据服务只是一个工具 - 在适当的地方使用它们。
查看一些高级概述文档，它看起来像WCF 数据服务具有相当广泛的可能应用程序。
The Bear in mind that the term "client" has a broad meaning, and can specifically include back-end systems, so in that sense the short answer would be yes. I havenb't heard of anyone using them seerver-side, but there's no reason why not; RSS is used to syndicate data between systems, WCF Data Services would be another way of doing that.
Maybe you're looking at this from a technology centric view-point, when really you need to be thinking more holistically? WCF Data Services are simply a tool - use them where ever appropriate.
Looking at some of the high-level overview docs it looks like the WCF Data Services have a pretty broad range of possible applications.