Jan 20

In these last 2 days I’ve been reading several documents on the ADO.NET Entity Framework. My main objective here is see if it is ready for being used in projects based on the DDD philosophy. Even though I still haven’t started writing code, it seems evident to me that EF is still a far away from being my persistence platform of choice. before going on, here’s what I intended to do in my current project:

  • start by building an adequate OO model to my current domain. Even though the model needs to accommodate some info that only matters to the db (ex.: Id and version fields), I would love it to be relatively PI;
  • Introduce the concept of repository and then build several implementations with different technologies in order to compare the final result;
  • keep it really simple. In fact, I kept it so simple that I’m not even using inheritance. Just plain references and collections to other entities and value objects.

With these objectives defined, I started looking at EF. After some searching, it become evident that I’d really have to change my objects (beside adding the ID and Version fields). Ok, so EF does not support POCO, but it does support something they called IPOCO. According to what I’ve seen (and I can be wrong), the idea is that instead of reusing the  EF default base class for entities, you could simply implement some interfaces (according to my research, you should be interested in implementing IEntityWithChangeTracker,IEntityWithKey and IEntityWithRelationships – of course,depending on your current scenario). btw, implementing these interface will also mean that you’ll have to change your properties’ code because you’re supposed to notify a “tracker” whenever one of the properties of your objects changes.

Besides the interfaces, you must also decorate your props/classes (and even the assembly) with some attributes. For example, you should use the EDMScalarPropertyAttribute for a primitive property that should be mapped onto a table column (not related, but isn’t this a violation of one  of the naming rules verified by FxCop? I’m glad that I’m not the only one breaking them 🙂 ). Hum…not looking good, right?

Now, I told you that I wasn’t using inheritance and this is  a pity because it seems like EF supports all forms of inheritance available on ORM mapping. And it even looks like you can configure these options by using the designer (ok, I didn’t checked it but I’ve found at least an example of these mappings which showed how to do that in the designer). Unfortunately, it seems like for adding value type mappings (I believe that the technical term in EF is complex types) you’ll really need to write the CSDL file by hand and then use the command line tool (edmgen.exe) to generate the remaining files.

Now, this (having to do it by hand – and I’m hoping that someone will drop a comment saying that there is a way of doing this in the designer) is really bad. One of the advantages that I thought EF had was providing a good designer (something which NH doesn’t have). Even though this is v1.0, i did expect to be able to do this from the designer as I didn’t really intended to get my hands dirty with the XML (If I really need to understand all those XML dialects they’ve created then I’ll probably use that from within the VS instead of using their designer). So, in the end I guess that this is minus 2 points for EF.

My last complaint of the day is related with references to other instances. You need to use some base class for those scenarios. For instance, if your object has a collection of other objects, each mapped to different tables, then you’re supposed to model that by using an EntityCollection<T> class. Again, I don’t like this.

So, this leaves me with one option: using a translation layer for mapping the entity generated classes into my domain classes .I don’t really see much value in using the entity generated classes as my domain classes and one of my objectives was to have a fixed set of domain classes. I do hope to have better reviews after starting to write some code since my first impressions are really that good.

Now, I’ve also seen a PDC vide which looks promising but i really didn’t find any release with those beta bits, so I’ll just keep using the current version until another more promising version is released.

1 comment so far

  1. Giovanni Bassi
    12:17 am - 1-21-2009

    I have seen several times people saying that only a small part of the development community uses or cares for POCOs, and even that MS should not care to implement it on EF. I don”t get it. Are we really so few?

    EF has a long way to go, it is V1, and we should understand that.
    IPOCO is a big laugh. Why would I reimplement everything that MS already did? What do I gain from that? Well, even if I do gain the liberty to inherit from some other class, the work that has to be done to implement all those interfaces (in every entity) is not so simple. And it looks like maintenance hell to me. The way is to use the designer, and accept it, not fight it.
    I guess there are scenarios where EF could be a good choice, but I wouldn”t use it in every project that an ORM might fit in.