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 BackgroundI'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 FrameworkHaving 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.
Questions? Thoughts? Hit me up
on Twitter
