用于服务/使用 OData 接口的实体框架的替代方案
我正在研究如何为我们的数据库设置 OData 接口。首先，我希望能够将数据库中的数据提取/查询到 Excel 中。最终，我想让 Excel 运行查询并通过 HTTP 从远程客户端提取数据，包括身份验证等。到目前为止
，我已经使用 Visual Studio 中的 ADO.NET 实体数据模型向导设置了一个工作（不稳定）原型和 VSTO 创建一个测试 Excel 工作表，其中包含一个从该 ADO.NET 界面提取的按钮。到目前为止一切正常，我可以通过 ADO.NET EDM 向导创建的实体/对象使用 Linq 查询数据库。
然而，我开始遇到这种方法的一些问题。我一直发现实体框架很难使用（事实上，也很难研究解决方案，因为有很多关于它和它的旧版本的争论）。一个例子是我无法弄清楚如何在向导为我的架构生成的 DataServiceContext 对象上设置 SQL 命令超时（而不是 HTTP 请求超时），但这不是我的问题的重点。
我真正的问题是，如果我想使用 OData 作为我的接口标准，我是否会坚持使用实体框架？是否有其他解决方案（最好是开源的）可以设置、服务和使用 OData 接口，并且比实体框架更易于使用且不那么臃肿？我曾看到有人提到 NHibernate 作为替代方案，但我见过的大多数比较线程都有几年历史了。现在还有其他选择吗？
非常感谢！
I'm researching how to set up an OData interface to our database. I would like to be able to pull/query data from our DB into Excel, as a start. Eventually I would like to have Excel run queries and pull data over HTTP from a remote client, including authentication, etc.
I've set up a working (rickety) prototype so far, using the ADO.NET Entity Data Model wizard in Visual Studio, and VSTO to create a test Excel worksheet with a button to pull from that ADO.NET interface. This works OK so far, and I can query the DB using Linq through the entities/objects that are created by the ADO.NET EDM wizard.
However, I have started to run into some problems with this approach. I've been finding the Entity Framework difficult to work with (and in fact, also difficult to research solutions to, as there's a lot of chaff out there regarding it and older versions of it). An example of this is my being unable to figure out how to set the SQL command timeout (as opposed to the HTTP request timeout) on the DataServiceContext object that the wizard generates for my schema, but that's not the point of my question.
The real question I have is, if I want to use OData as my interface standard, am I stuck with the Entity Framework? Are there any other solutions out there (preferably open source) which can set up, serve and consume an OData interface, and are easier to work with and less bloated than the Entity Framework? I have seen mention of NHibernate as an alternative, but most of the comparison threads I've seen are a few years old. Are there any other alternatives out there now?
Thanks very much!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
WCF 数据服务提供用于定义自定义提供程序的可扩展模型。所以你的主要问题的答案是：不，你并没有被实体框架所困扰。除非您有想要使用 EF 解决的某些问题的真实示例，否则您的问题的其余部分大多是主观的和争论性的。
WCF Data Services provide extensible model for defining custom providers. So answer to your main question is: No you are not stuck with Entity framework. Unless you have real example of some problems which you would like to solve with EF the rest of your question is mostly subjective and argumentative.
我们调查了完整的开发冲刺（15 天）2 人使用我们的 DTO 在我们的服务层上尝试 ODATA...Proto 位于现实世界中，包括与外部服务提供商的后端集成、具有多个前端连接的真实用例到同一个后台，每个上下文都有多个数据库的真实数据，数百万条记录。我们发现唯一有效的解决方案是使用实体框架...不太容易定义自定义提供程序，如果所有内容都在内存中（可扩展性不太好），则效果很好，当 DTO 包含非原始属性时会发生崩溃。需要创建一个新类来实现 IQueryable 和 IQueryProvider 接口，但仍然需要在大切换情况下进行映射，以根据 URL OData 查询调用正确的服务...并且很难插入与外部提供程序数据的集成查询...
如果您使用实体框架，ODATA 非常好...
We have investigates a complete sprint of development (15 days) 2 person to try ODATA over our service layers using our DTO... Proto was in a real world including back end integration with external service provider, real use case with multiple front end connect to the same back office, real data with multiple database per context, millions of records. We found out that the only solution that works well is if we use entity framework... not very easy to defined custom provider, works well if everything is in memory(not very scalable), crash occurs when DTO contains non-primitive properties. Need to create a new class to implement IQueryable and IQueryProvider interfaces, but still need to do mapping in big switch case to call the proper service based on the URL OData query... and had a hard time to plug the integration with external provider data querying...
ODATA is very nice if you use entity framework...
我们也不能使用实体框架。由于我们有一个使用大量智能缓存的高性能解决方案，因此实体框架会跳过这一点，并直接连接到数据库服务器，启动各种复杂查询的方式来仅执行简单的选择。它正在连接其他表，我不需要我调查的请求中的数据。
对我来说，实体框架只不过是性能杀手。所以你的问题+1！
We also can't use the entity framework. As we have a high performance solution that uses a lot of intelligent caching, the Entity framework just skips that, and connects directly to the database server, launching all kind of way to complicated queries to just do a simple select. It's joining on other tables for which I don't need the data in the request I investigated.
For me Entity framework is nothing but a performance killer. So +1 for your question!