title: Alternatives to the Entity Framework for Serving/Consuming an OData Interface
body: <p>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.</p>
  
  <p>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.</p>
  
  <p>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.</p>
  
  <p>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?</p>
  
  <p>Thanks very much!</p>