业务逻辑在哪里使用实体框架进入WCF数据服务？

Question

我正在研究如何围绕实体框架上下文创建WCF数据服务，您也可以将其作为EF上下文使用。

Creating an OData API for StackOverflow including XML and JSON in 30 minutes

我真的刚开始看这个，但我想知道业务逻辑会去哪里？作为一项服务，我希望你不能在没有经过验证的情况下自由添加/删除等。

如果我编写MVC应用程序来使用此服务，我将如何最好地实现业务逻辑。不是简单的属性级别验证，你可以用属性做，但更复杂的东西需要先检查数据存储等。

Answer 1

您可以在Data Service类中添加一些内容，但是您可以在那里做什么和不能做什么。当然，你可以在客户端上面放一些服务，但这也不理想。

我只花了几周时间使用WCF数据服务，但你突出（其中一个）它的大问题 - 缺乏灵活性。它对于快速开发和敲击LOB应用程序来说非常棒，但任何经过深思熟虑的设计都很难实现。我需要在我的实体模型中包含对象，只是为了允许它们通过服务公开，而我只是试图用简单的属性扩展这些类，我感到非常头痛。

我只建议将WCF数据服务用于需要极快开发的简单应用程序 - 例如，一天或两天的开发周期。其他任何事情都值得用常规WCF服务，编写自己的数据层等等。

Answer 2

听起来您需要自定义数据服务提供商(msdn link)。它们非常强大，可以让您完全控制所有的读/写逻辑。

例如，我写了一个在更新提供程序中强制执行许可逻辑的程序。

Answer 3

根据您的具体需求，听起来Web API可能非常合适。 Web API可能永远不会获得WCF数据服务所具有的全部OData支持，但它确实使某些事情更容易（如添加业务逻辑）。我非常有信心Web API对OData的初始支持将涵盖大量用例，并且这种支持将随着时间的推移而增长。

Answer 4

虽然自定义数据提供商肯定可以做任何你想要的事情，如果你有一个复杂的架构，很可能是一个很好的解决方案，当我试图通过客户端保存并发现时，我并不感到非常激动我必须在我的Context中实现我的IUpdatable接口。（我试图从我的上下文和DataService构建一个存储库模式）。

我确信它对很多人来说非常有用，但我真的只需要EntityProvider已经包含的功能，并且没有时间在我的项目计划中来计算自定义提供程序的Iupdatable部分，所以我的团队，特别是Geoff，坚持使用实体提供程序，并使用变更和查询拦截器通过服务器上的业务逻辑类路由DataService请求。它提供了一个中心控制点。我们使用它们来提供安全检查，运行计算和其他插入/更新操作等。结果很棒。您还可以使用服务方法作为向客户提供特定业务逻辑功能的另一种方法。