+972 52-548-6969
A guide into OR/M implementation challengesReasoning
Davy Brion, one of NHibernate’s committers, is running a series of posts discussing building your own DAL. The reasons for doing so varies, in Davy’s case, he has clients who are adamantly against using anything but the Naked CLR. I have run into similar situations before, sometimes it is institutional blindness, sometimes it is legal reasons, sometimes there are actually good reasons for it, although it is rare.
Davy’s approach to the problem was quite sensible. Deprived of his usual toolset, he was unwilling to give up the advantages inherent to them, so he set up to build them. I did much the same when I worked on SvnBridge, I couldn’t use one of the existing OSS containers, but I wasn’t willing to build a large application without one, so I created one.
I touched about this topic in more details in the past. But basically, a single purpose framework is significantly simpler than a general purpose one. That sounds simple and obvious, right? But it is actually quite significant.
You might not get the same richness that you will get with the real deal, but you get enough to get you going. In fact, since you have only a single scenario to cover, it is quite easy to get the features that you need out the door. You are allowed to cheat, after all :-)
In Davy’s case, he made the decision that using POCO and not worrying about persistence all over the place are the most important things, and he set out to get them.
I am going to shadow his posts in the series, talking about the implications of the choices made and the differences between Davy’s approach and NHibernate. I think it would be a good approach to show the challenges inherit in building an OR/M.
More posts in "A guide into OR/M implementation challenges" series:
- (28 Aug 2009) Custom Queries
- (28 Aug 2009) Lazy loading
- (27 Aug 2009) The Session Level Cache
- (26 Aug 2009) Hydrating Entities
- (25 Aug 2009) CRUD
- (24 Aug 2009) Mapping
- (24 Aug 2009) Reasoning
Comments
one minor clarification: those customers are against using anything but the naked CLR only when it comes to data access code. For other stuff, they do let us use existing libraries (we use Windsor on their projects for instance).
You have a small typo: "the challenges inherent", not "the challenges inherit".
I've done the same thing before, in the army; sounds like an interesting series of posts indeed.
NHibernate is open source - download the source, call it Company.DataLayer.dll - problem solved. :)
thanks, fixed
Comment preview