我正在为新的 Web 应用程序评估一些技术。哪个应该使用带有 Web API 的 EF5 和 Knockout JS。我想在返回 IQueryable 时利用 OData 功能，但目前遇到了问题，如何将我的 EF 模型转换为我的业务模型。
据我所知，如果我想要一个更复杂的数据库（计算列、存储过程……），我应该使用 DB First 方法。（如我错了请纠正我）
因为我需要使用 DB-First 方法并希望我的模型独立于数据库，所以我需要在 EF-Models 之外创建它们。当我从 DataLayer 返回我的业务模型为 IQueryable 时，我失去了直接在数据库上执行其他查询的可能性，而是直接在 ASP.Net 服务器上执行它们。
当然，我不打算在 OData 上运行复杂的查询，并且无论如何都会将这些查询作为附加操作来实现，但在速度较慢的客户端（智能手机，...）上限制返回的数据并直接在服务器。
有没有办法摆脱这种困境，仍然能够使用 OData？
问候彼得
您可以尝试使用 Code First 和 EF 迁移来创建/升级数据库。通过迁移，您可以创建自定义迁移，这些迁移可以只是 SQL 脚本，以实现 Code First 本身无法自动完成的任务。数据库优先方法也很好。
问问自己是否真的想要/需要支持多个后端。EF 可以，但很难维护。在这种情况下，我假设您的概念模型（csdl）对于所有数据库都是相同的，但您将拥有多个特定于商店的模型（ssdl 文件）。由于您的模型对于所有数据库都是相同的，因此无论您使用什么数据库，您都将拥有相同的 C# 类型。
当支持多个数据库时，您将无法对数据库运行 SQL 查询（或者更具体地说，如果您针对不同的数据库运行特定于一个数据库的 SQL 查询，则会出现异常），但理想情况下您不应该需要它。在最坏的情况下，您可能会将您希望在 SQL 中编码的逻辑包含在所有数据库中都存在的存储过程中。同样，我不知道何时需要这样做（唯一想到的是性能），但由于您计划使用 OData，除非您开始使用服务操作，否则无论如何您都无法运行这些查询。
由于无论数据库如何，您的概念模型都是相同的，因此无论数据库如何，您都将拥有相同的类型。您可以尝试将这些用于 DataLayer 和业务模型（尤其是如果您使用 POCO）。另一种方法是使用 POCO/DTO。（我没有在 Web API 中尝试过 OData 支持，但使用 WCF 数据服务，服务本身实际上会使用 EF 类型，因此您甚至无法告诉服务使用不同的类型集）。
只要您的转换不是太糟糕，您实际上不会失去使用 DB 优先模型对业务模型执行查询的能力。例如，我有一个 OData 服务，它有一个 PersistedCustomer（数据库模型）和一个客户（业务模型）。使用 EF5，我可以编写将 IQueryable 转换为 IQueryable 的 LINQ，针对 IQueryable 进行查询，并且 EF 可以将标准转换回原始数据库。