Entity framework in a layered architecture?

Question

Doing some experiments around WCF and Entity Framework. A couple of questions.

Option 1:

I understand that entity framework classes can be serialized over WCF directly, with sp1 onwards. How ever, I would like to know how scenarios like delay loading, eager loading, context management etc is handled in this, if they are handled at all?

Option 2:

Another alternative might be to use EFPocoAdapter, to have a plain POCO wrapper on top of the entity framework, instead of exposing entity framework classes directly. http://code.msdn.microsoft.com/EFPocoAdapter . Has anybody used this? Any Thoughts in this direction?

Other Thoughts:

About ADO.NET data services - As I understand ADO.NET data services can't be configured over remoting (nettcp binding)? It supports only http based access. We all know that binary serialization is slower.

Any pointers or any other options?

Answer 1

It's a very bad idea to expose EF classes over WCF. Microsoft made some serious mistakes that prevent this from being a useful scenario. They've exposed the entities as data contrracts, but also the base classes of the entity, and for backward links, expose two copies of the link.

On the other hand, it appears that ADO.NET Data Services have some magic that allow something close to this to work. Read the SilverLight article in this month's MSDN Magazine for an example, from the client side, of using ADO.NET Data Services.

Answer 2

I've done some digging on this, and here are my findings on this.

ADO.NET Data Services:

You can use ADO.NET Data services (you need SP1) to expose your Entity framework over the wire, with almost zero code. But as I understand, the only limitation is, the transaction is over HTTP. That means, there is a small over head in terms of serialization (we all know binary serialization is faster), but the advantage is the speed of implementation for our services.

I got an unofficial word from John [http://twitter.com/John_Papa] on this - "Definitely more options with wcf. More work in most cases too. Astoria exposes entities easily. Perf diffs are negligible in most cases"

The advantages - You don't really need to write any services at all - You can just hook the validation and security logic around the data services and entity framework and we are done. Ideal if you are consuming data centric services over http - in scenarios like having a silverlight client, or a winform/wpf front end over http.

Exposing Entity Framework over WCF:

With SP1, there is lot of support for employing entity framework in layered architectures. This includes support for eager loading and context management. Of course, in this case, we need to write the services (and the logic behind our methods). Or if we have the entity framework model totally alligned with the db, we could generate most of the services, which includes the methods we need.

Recommending you to read this http://msdn.microsoft.com/en-us/magazine/cc700340.aspx

Another alternative might be to use EFPocoAdapter, to have a plain POCO wrapper on top of the entity framework for dtos, instead of exposing entity framework classes directly. Right now it is a compass project for next version of Entity framework http://code.msdn.microsoft.com/EFPocoAdapter.

Answer 3

Not to bring up an old post but... I found this listing when dealing with the exact same problem. We have WCF services and an Entity Framwork domain model. In the end I ended up making a T4 based on work by Danny Simmons that takes the EDMX and builds POCO message classes along with extension methods that map entity.ToMessage() and message.ToEntity(objectcontext).

This seemed like the best intermediate approach until .NET 4.0 since it requires no additional external project dependencies or hoops to jump through like the other methods I found (based on PostSharp).

If anyone else thinks this approach would be helpful let me know and I will post the link to the TT file on our googlecode site.