1

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

在 30 分钟内为 StackOverflow 创建一个 OData API，包括 XML 和 JSON

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

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

4

4 回答 4

2

您可以将一些放在数据服务类中，但您可以在那里做什么和不能做什么受到限制。然后当然你可以把一些放在服务上面的客户端中，但这也不理想。

我只花了几周时间使用 WCF 数据服务，但您强调了它的（其中一个）大问题 - 缺乏灵活性。它非常适合快速开发和开发 LOB 应用程序，但任何经过深思熟虑的设计都很难实现。我需要在我的实体模型中包含对象只是为了让它们通过服务公开，而我只是想用一个简单的属性来扩展这些类，我非常头疼。

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

于 2012-07-19T01:35:08.163 回答
2

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

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

于 2012-07-19T03:08:52.103 回答
1

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

于 2012-07-19T15:59:18.300 回答
0

虽然自定义数据提供者肯定会做任何你想做的事情，如果你有一个复杂的架构，这对你来说可能是一个很好的解决方案，但当我试图通过客户端保存回来并发现我必须这样做时，我并没有很兴奋实现我的 IUpdatable 接口作为我的上下文的一部分。（我试图从我的上下文和数据服务中构建一个存储库模式）。

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

于 2012-07-24T14:58:51.767 回答