After having mastered Linq2Sql and come a long way towards understanding NHibernate, I’ve recently begun looking at a middle-of-the-road solution: Entity Framework.
My main goal here was to see if I could make it work in a domain driven application and the results are quite interesting.
The first thing I wanted to know was if I could use POCO classes. The answer is yes, though it involves first generating your model via the Designer and then removing the code generation setting. Even then, the Designer must remain in the solution in order for the csdl, ssdl and msl mappings to be embedded. If you are dead set on splitting your solution up into several projects, this isn’t ideal. Remember though, you can develop in a domain driven way whether or not the solution is separated into smaller projects or not.
The second thing I wanted to know was if it would still be dependant on an ObjectContext. The answer here is yes. It still requires an ObjectContext, though it will be a POCO version.
Ok, so the first two points seemed to rule out using EF, but I decided to press on to see if I could find out more.
I started a fresh project and added an EF Designer to it, then generated the model based on the database I am using in my forum application, allowing it to generate the code as well. Everything was generated correctly. But were the entities good for domain driven design? If not, could they be made to be?
The first thing I looked at was the Forum entity, which was generated from a self-referencing table. Using the default setting upon generation, it included a back reference to the parent Forum, as well as it’s foreign key. Ok, not very domain-like, but could I fix it?
I took a look at the entity and it’s properties via the Property tab and saw some very interesting settings. I set the public getters and setters for the ParentId and Parent properties to “protected”. One nice thing here is that you can set the setter and getter individually. Another nice thing is have a completely hidden mapped property. This is something NHibernate cannot do. It requires at least a public getter in order to use Map(x => x.Property).
The next thing I did was look at the one to many collection of child forums. I hid the “Children” collection in the same manner and renamed it “children” (lower case). I then added a partial to the project and exposed it as an IEnumerable<Forum> with accessor methods like AddChild(child).
Now my entity was looking more like a real domain object, but what about the constructors? Were they compliant as well? I took a look at the code and saw that NO constructors were defined for these entities, merely a single static factory method (not a real great one either). This did mean, however, that I could add a protected default constructor and a public domain-centric constructor to the partial.
After applying these concepts to the other entities, the result was programmatically no different from that of NHibernate.
I then took a look at how things are affected should something change. After making a few changes, I revisited the Designer GUI and brought up the “Model Browser”. It was fairly easy to understand and manipulate. Shortly after opening it, I had my changes isolated and fixed up.
I then looked at the raw xml in the edmx and said “heck no”. I won’t even try to understand that. But then again, why would I? The designer manages that for me. As long as the designer is easy to use, just leave the xml alone.
The conclusion is that EF 4.0 can indeed be used to generate true domain entities, with two caveats:
- It places code and mapping in the same project.
- It uses a mix of generated and partial classes to work, instead of pocos.
If you can live with these two things, and you work better with a visual gui, then EF 4.0 may be the persistence technology for you.
Perhaps when the Poco CTP goes through beta and to release, EF may be even more of an all around solution, but for now, you’ll to live with the caveats above.
Thanks for reading.