使用OData与EF实体分离的模型？

Question

我们正在考虑将OData用于我们的下一个项目。有很多例子说明如何将OData与Entity Framework一起使用。只要在REST接口上公开数据库实体1：1，这些示例就会非常简单。 为了将我们的数据库实体与api模型分离，我们曾经使用automapper对它们进行映射，然后从我们的存储库返回它们。当然，这样，我们失去了ORM给我们带来的许多安慰。但过去告诉我们，使用数据库实体的一对一表示通常比利用EF / Linq2SQL的功能产生更多问题，即使使用POCO也是如此。

如果我们想要保持api模型分离并考虑使用OData，那么就会出现很多问题。 OData在查询资源方面提供了很大的灵活性，但是api客户端具有所有自由，它必须以某种方式转换到数据库。在内存中应用查询选项显然不是一个选项，因为它要求您加载整个表。只支持一些查询选项似乎也不是OData背后的想法。

那么，我们是否被迫将我们的实体直接暴露给我们的api以有意义的方式使用OData？

Answer 1

仅仅因为你采用了OData，并不一定意味着你必须为每个资源实现整个事情。

我一直对OData的“魔盒”方面有点怀疑。通过将数据实体公开为资源，您将公共服务定义耦合到底层数据库系统。您的客户端集成将极易受到更改。

但是，这是实现的问题，而不是标准本身。 OData可以很好地完成很多工作，并且可以成为在API中建立语法一致性的有用方法。

您可以自由地实现查询功能的子集。这在.Net实现中是隐含的，因为 ODataValidationSettings 类允许您指定要支持的函数，运算符和查询选项。您还可以通过直接解析 ODataQueryOptions 对象来手动控制查询提交到底层数据存储的方式。

Answer 2

您需要做的是投影。这是您在linq查询结束时使用select语句将结果投影到其他类的位置。这样就可以完全抽象出从源返回的数据，同时仍然可以获得对此调用的任何查询仍然在数据库中执行的好处

https://nrepository.codeplex.com处有一些演示代码，它们在使用EF的OData控制器中显示了这一点。