Basta-On-Tour Wrap Up Day 1: Entity Framework

Well, this is a very short and brief wrap up of the 1st day here at the Basta! On Tour in Düsseldorf. The session was about Entity Framework, hold by Dr. Holger Schwichtenberg, an MVP of ASP.net.

My Background
I'm actually coming from the Java world where I worked with JDO, JPA and Hibernate. Hibernate is very flexible which implies however a lot of configuration that has to be done and understood. Anyway, once you got it, you're really fast.
I'm now working already for more than three years in the .Net world. What we did at work is to develop our internal ORM mapper, basically a code generation tool that created everything from the stored procedure, mapping the result in a proper entity as well as the different kind of methods through all the layers of the application for reading/writing data. Now, while this works quite well in simple scenarios, a major drawback was that it didn't support relations among objects. Some workarounds allowed to retrieve a whole object graph with its relation from the DB but it was cumbersome and time consuming. This is why we are planning to exchange our own ORM with an existing one.

Entity Framework
Having just finished my studies and having been quite busy (therefore), I had never the occasion to take a closer look at the Entity Framework rather than some online code samples, video tutorials and such stuff. Generally speaking it made a quite good impression to me but today's presentation puzzled and somehow also disappointed me a bit. The integration with Visual Studio is certainly one of the big pros here. If you know the different XML config files you need for having Hibernate up and running, EF is much simpler (but less flexible and powerful). Of course one could claim to use annotations in Hibernate, but I normally don't like to clutter up my entities with persistence-related stuff directly.
The things that puzzled me a bit is first of all the introduction of the DbContext in EF 4.1. Why did Microsoft introduce the DbContext rather than optimizing the already existing ObjectContext? First of all, the name is misleading, as I find ObjectContext are more representative name for what is actually going on. IMHO, this creates confusion in the community. For instance, while the DbContext seems to be as an improved, more clean evolution of the ObjectContext, there are still some things which are supported in the ObjectContext but not in the DbContext. Just to mention one example: I'll definitely like to use the new T4 templates introduced with EF 4.1 which generate nice clean POCO objects. This is great, but when I use those I have to use the DbContext (at least that was what I understood from today) but that again implies that I cannot use the compiled queries feature which is just supported by the ObjectContext!! WTF?!? Moreover there are a couple of inconsistencies in the design of the ObjectContext and DbContext as for instance where certain properties like the Connection object are located, calls to manual eager loading and so on. These are things where I would have expected a more uniform design, given that these are always provided by the MS EF team itself.

There are some other points which weren't that nice but would take too long now to list here as it's already late ;). Overall it isn't that bad as my 1st résumé might seem here as there are many points you can live with, but - as said - Microsoft could have done better...and I'll definitely look at NHibernate too ;). I'm looking forward to tomorrow's sessions which are about EF best practices, its usage in distributed architectures. There are some other interesting sessions about ASP.net MVC and JavaScript patterns as well.
Kindle

Comments

0

Your ad here?