Entity Framework and ObjectContext n-tier architecture

Question

I have a n-tier application based on pretty classic different layers: User Interface, Services (WCF), Business Logic and Data Access.

Database (Sql Server) is obviously quered throught Entity Framework, the problem is basically that every call starts from user interface and go throught all the layers, but doing that I need to create a new ObjectContext each time for every operation and that makes performance very bad because every time I need to reload metadata and recompile the query.

The most suggested pattern it would be the one below and it is what I'm actually doing: creating and passing the new context throught business layer methods each time the service receives a call

 public BusinessObject GetQuery(){     
   using (MyObjectContext context = new MyObjectContext()){ 
      //..do something  }    }

For easy query I don't see any particular dealy and it works fine but for complex and heavy query it makes a 2 seconds query to keep going for like 15 seconds each call.

I could set the ObjectContext static and it would solve the performance issue but it appears to be not suggested by anyone, also because I won't be able to access the context at the same time from different thread and multiple calls raise an exception. I could make it thread-safe but mantain the same ObjectContext for long time makes it bigger and bigger (and slower) because the reference it imports each query it execute a query.

The architecture I have I think it is the most common so what is the best and known way to implement and use ObjectContext?

Thank you, Marco

Answer 1

In a Web context, it's best to use a stateless approach and create an ObjectContext for each request.

The cost of ObjectContext construction are minimal. The metadata is loaded from a global cache so only the first call will have to load it.

Static is definitely not a good idea. The ObjectContext is not thread save and this will lead to problems when using it in a WCF service with multiple calls. Making it thread save will result in less performance and it can cause subtle errors when reusing it in multiple requests.

Check this info: How to decide on a lifetime for your ObjectContext

Answer 2

Working with a static object context is not a good idea. A static context will be shared by all users of the web application meaning that when one user makes modifications to a context such as calling saveChanges , all other users using the context will be affected (this would be a problem when supposing they have added or updated data to the context but have not called save changes). The best practice while working with object context is to keep it alive for the period of the request and use if to perform any atomic business operations. You would want to check out the UnitOfWork pattern and repository pattern

uow

uow and repository in EF

If you feel you are having performance issues with your queries and there is a possibility that you would reuse your query , I would recommend you use precompiled linq queries. You can check out the links below for more info

precompiled linq julie lermann

precompiled linq

Answer 3

What you show is the typical pattern to use a context - by request, similar to using a database connection.

What makes you think the bad performance is related to recreating the context? This is very, very likely not the case. How did you measure this impact?

If you have such performance critical code that this overhead truly matters you should not use Entity Framework since there always will be some overhead, even if the overhead should be very little in the general case. I would start focusing on your data model though and the underlying data store which will have a much larger impact on your query performance. Have you optimized your queries? Did you put indexes everywhere you need them? Can you de-normalize the data to remove joins?