首先，这是我的第一个Stack Overflow问题，如果我弄错了，请提前道歉！
我正在为内部使用的CRM数据库创建服务端点。有几个应用程序想要读写这个数据库，因此暴露WCF服务似乎是最好的方法。
我开始使用ORM的实体框架，业务逻辑层的CSLA和用于与客户端应用程序通信的标准WCF服务。一切顺利，直到我看了一下WCF数据服务并被可爱的REST界面所吸引，AJAX客户的易用性以及使用新技术的乐趣！
我现在用一个WCF数据服务替换了大部分WCF服务，该服务直接暴露了实体框架模型，绕过了CSLA层。这对于只读操作非常有用，但如果没有一些业务逻辑，我就无法执行其他CRUD功能。
我一直在研究拦截器，我当然可以将业务登录放在那里，但我实际上想要拦截POST / Add操作，将值映射到相关的CSLA BusinessBase类并让它进行所有验证和最终保存到数据库中。我试过这个，当CSLA对象按预期工作时，底层的WCF数据服务框架也会保留其版本，所以我在db中得到两个条目。
因此我有几个问题：
1）我可以完全拦截变更请求，让我自己的业务对象处理它然后取消WCF数据服务而不抛出异常吗？
2）是否有更好/标准的方法将业务逻辑层添加到WCF数据服务堆栈？到目前为止我还没找到。
提前致谢，
戴夫
答案 0 :(得分：1)
不幸的是，如果WCF数据服务的基础提供程序是实体框架，则您无法自行完成所有操作。目前，在这种情况下，我们不支持完全替换部分处理管道。
另一方面，你可能会玩一些技巧。您可以在实体框架上执行此操作。最新版本的EF应该让你覆盖SaveChanges调用，这样你就可以在那里做任何你想做的事情。因此，您可以自行处理change itnerceptor中的Add操作，然后在SaveChanges中恢复由WCF Data Services创建的更改，并仅从更改拦截器提交更改。或者甚至更好，只需在SaveChanges中做所有事情。
可能还有其他不错的技巧可以使用EF，而WCF数据服务可能会在不知情的情况下使用，但我不是EF专家可以肯定的。
目前，拦截器是将业务逻辑分层为WCF数据服务的标准方法（适用于包括EF在内的任何提供商）。
另一种方法是远离REST一点点。您可以禁止对给定实体集的POST请求（您可以从更改拦截器中抛出）并添加服务操作以在您自己的代码中执行添加。在这种情况下，您可以完全控制，但客户将更难以开始工作。