Lately I was validating the usability of the entityFramwork 1.0 for our SOA architecture. We have a stateless service environment with WCF. So calls of any operationcontract of the some servicecontract creates all the time new Wcf ServiceObjects. To achieve this, the servicecontract implementing class is hosted with:
fServiceHost = new ServiceHost(typeof (DataLayer.WCF_Interface.DataLayerService));
fServiceHost.Open();
Now, how do we build in the database access with EF into the Servicecontract implementing class?

First I looked in EF for posibilities to construct something like that:

Sample 1:

public class ServiceContractImplementingClass
{

static EFEntities entities;

ServiceContractImplementingClassCtor()
{
        if entities == null
       entities = new EFEntites(”Databaseconnectionstring”); //creates the in EF OR mapper instance 

}

//[OperationContract]
Location[] GetBusinessLocations()
{
    // create a low cost Database object from the ObjectContext
    var locs = from a in entities.GetNewSession().Locations select a;
   ———-
   return locations;

}
———–….————

}

Here in general I have one ObjectContext. For each stateless call to the OperationContract a lightweight Session would be created. The ObjectContext would be created once, the sessions more than once.
After long deep search I found no supporting constructs wether in EF 1.0 nor in EF 2.0.
Now I told myself, maybe that could be solved using somthing like that in the ServiceContract Implementing class:

Sample 2:

// only for readonly scenarios!!!
public class ServiceContractImplementingClass
{

static EFEntities entities;
private static EFEntites GetEFEntities()
{
     if entities == null
     entities = new EFEntites(”Databaseconnectionstring”); //creates the in EF OR mapper instance
     return entities;

}
//[OperationContract]
Location[] GetBusinessLocations()
{
    var locs = from a in GetEFEntities().Locations select a;
   ——————–
    return locations;

}
———–
}

This approach made sure that no costly intialisation of the ObjectContext was to perform at every call of the operation contract. Of course the ObjectContext is not threadsafe. I am aware of that being very seldom, but I have  in my scenario only read operations no write accesses, so I should not mind Mutlithreading, stale data …. After having written an out of the box stresstest with Visualstudio accessing one static instance of EFEntities, I found I run into problems. There was an exception, stating that some column of table x in the database could not be accessed. Mind, I was only reading all myself alone the database. In that case I would have to make sure by hand that the EFEntities accesses are synchronized(with Locks) even if I have only read access. Wow! Eventually I would end up with serial access to the db even for read operations. Please mind that for read/write scenarios that sample 2 is of course not approbiate and you would end up wit sample 3!
BTW: this method was almost as fast as the good old create DatabaseConnection–> DataAdapter.Fill(Dataset) approach.

So I went back to the Microsoft backed pattern:

Sample 3:

public class ServiceContractImplementingClass
{

//[OperationContract]
Location[] GetBusinessLocations()
{

using (var db = new EFEntities(”DBConnectionString”))
{
        var locs = from a in db.Locations select a;
}

………………. return…
}
—————————–
}

Now that creates for every ServiceContractImplementingClass calls a new ObjectContext. I found after stress testing that somhow the db creation gets faster after the first call due to caching, but is was still slower than my second solution. unacceptable slow since with every call the ObjectContext had to created!
Now I asked for advice in some forum or other. In the MS Forum there was not really help available. More or less they were using EF in Desktop apps, there the application holds an ObjectContext refernce as long as the app is executed.
BTW: In that scenario EF is excellent, most of all because of the rather good LinqToEF implementation(better than LinqToNHibernate).

In the Wrox forum of (by the way very comprehensive) WROX book Professional ADO.NET 3.5 with LINQ and the Entity Framework ISBN: 978-0-470-22988-0 from Jennings, I got some valuable feedback: http://p2p.wrox.com/book-professional-ado-net-3-5-linq-entity-framework-isbn-978-0-470-22988-0/72707-comparing-performance-linq-entities-outofband-sql-updates.html

So thats that! I was downloading beta of VS 2010 with .NET 4.0 later then and found no extended ObjectContext -no POCOS, I admit I did not delve too much into that… but I gave up with EF for my intended scenario..

If there is someone who knows there I am possibly mistaken, I would appreciate any comment. We are very much .NET in the Company but we found ourselves forced to go for NHibernate.