我对 ADO.Net 数据服务有点困惑。
它只是用于创建 RESTful Web 服务吗？我知道 WCF 始于 SOAP 世界，但现在我听说它对 REST 有很好的支持。ADO.Net 数据服务也是如此，如果您不能从面向资源的视图中查看所有内容，您可以使其在 RPC 模型中工作。
至少从我最近看到的演示来看，ADO.Net 数据服务似乎是在服务器上的 WCF 堆栈上构建的。如果我错了，请纠正我。
我不打算开始 REST 与 SOAP 辩论，但我想事情不再那么清晰了。
关于在哪里使用什么的任何建议或指南？
在我看来，ADO.Net 数据服务用于创建与您的域模型紧密结合的宁静服务，即模型本身已发布，而不是某种形式的 DTO 等。
将它用于 RPC 风格的服务似乎不太合适，但不幸的是，即使是一些非常基本的功能（例如能够执行过滤计数等）也不可用，这通常意味着您最终会使用一些 RPC 来满足您的客户，即您可以显示分页网格等。
WCF 3.5 pre-SP1 是一个相当弱的 RESTful 平台，在 SP1 中，Uri 模板和 ATOMPub 支持的可用性都得到了改进，因此它变得更有能力，但它们并没有真正提供任何优雅的解决方案来支持说 JSON 、XML、ATOM 甚至更深奥的东西，比如像 CSV 这样的有效负载，而不必使用 URL 重写和不同的扩展名、方法名称修改等 - 而不是仅仅根据请求的标头选择序列化器/反序列化器。
使用 WCF 仍然很难创建在更自然的宁静庄园中工作的服务，即资源包括 url，并且您可以通过导航它们来转换状态 - 这有点笨拙 - ADO.Net 数据服务使用它的 AtomPub 做得很好虽然支持。
我的建议是使用 Web 服务，它们自然是服务并且强制执行强大的服务边界，将 ADO.Net 数据服务用于丰富的 Web 样式客户端（网站、ajax、silverlight），其中 url 查询的可组合性可以节省大量的管道和你的域模型是非常基本的......如果你需要完全控制信息，即如果你要为其他开发人员发布 API在社交平台等上消费
我的 2ø 值！
在处理根本不与数据库交互的代码时，使用 WCF 的 rest 绑定非常有效。HTTP 动词并不总是必须与数据提供者背道而驰。
实际上，有一些选项可以过滤和跳过以获取类似页面的功能。