我一直在寻找如何围绕实体框架上下文创建WCF数据服务，您也可以将其作为EF上下文来使用。业务逻辑在WCF数据服务中使用实体框架进入哪里？
Creating an OData API for StackOverflow including XML and JSON in 30 minutes
我真的开始考虑这一点，但我不知道哪来的业务逻辑去了？作为一项服务，我希望你不能在没有验证的情况下自由地添加/删除等。
如果我写了一个MVC应用程序消费这种服务，我将如何最好地实现业务逻辑。需要检查数据存储第一等
这听起来像你需要一个自定义数据服务提供商(msdn link)。它们非常强大，可以完全控制所有读/写逻辑。
比如我写了一个强制执行的更新提供我们的授权逻辑。
你可以把一些数据服务类，但你被限制为不简单属性级的验证，你可以带属性做，但更复杂的东西，你可以和不能在那里做。然后当然你可以在服务之上放置一些服务，但这也不是很理想。
我只花了几个星期与WCF数据服务，但你突出（之一）的大问题吧 - 缺乏灵活性。对于快速开发和LOB应用程序而言，这真是太棒了，但任何有意设计的东西都很难实现。我需要在我的实体模型中包含对象，只是为了让它们通过服务暴露出来，而我只是试图用一个简单的属性来扩展这些类而非常头痛。
我只建议使用WCF数据服务是需要非常快速的发展平凡简单的应用程序 - 一两天的开发周期，例如。对于常规的WCF服务，编写自己的数据层等等，其他任何事情都是值得的。
根据您的具体需求，这听起来像Web API可能是一个很好的选择。 Web API可能永远无法获得WCF数据服务所具有的全部OData支持，但它确实使某些事情更容易（如添加业务逻辑）。我相当相信Web API对OData的初始支持将覆盖大量的用例，并且这种支持将随着时间的推移而增长。
虽然自定义数据提供程序肯定会做任何你想做的事情，如果你有一个复杂的体系结构，可能是一个很好的解决方案，但当我试图通过客户端存回时发现并不是很激动我必须实现我的IUpdatable接口作为我的上下文的一部分（我试图从我的上下文和DataService构建存储库模式）。
我确定这对于很多人来说非常有用，但是我真的只需要EntityProvider已经包含的功能，并且没有时间在我的项目计划中将自定义提供程序的Iupdatable部分取出，所以我的团队，特别是Geoff，坚持使用Entity Provider，并使用Change和Query Interceptors通过服务器上的业务逻辑类路由DataService请求。它提供了一个中心控制点。我们使用这些来提供安全检查，运行计算和其他操作插入/更新等，结果很好。您还可以使用服务方法作为向客户提供特定业务逻辑功能的另一种方式。
（我真诚地希望这是建设性的反馈意见。）虽然我完全同意WCF数据服务缺乏灵活性这一事实，但我认为诸如“被迫将数据库实体暴露给客户端”这样的特征表明对WCF DS的内容并不完全了解。正如Jason所说，定制提供商可以让你做任何你想做的事情。我很希望看到微软或这个社区放在一起的提供商，它允许比内置提供商更多的可扩展性。 – 2012-07-19 15:55:55
@ MarkStafford-MSFT感谢您的反馈。正如我注意到的，我只用了几周的时间就使用了Data Services，并突出了我的经验。您突出显示的特定句子没有按照我的意思阅读，现在我正在更改它。 – 2012-07-20 01:22:57
感谢您以正确的精神采取反馈。 :) – 2012-07-20 17:06:34