I wasn't planning on blogging tonight but I was answering some questions in NHibernate's forum and I see a lack of understanding of a crucial principle in embracing OR/M tools.
I have been trying to log what I have learned and am learning in effectively using an OR/M to improve development. Specifically, I am using NHibernate...if some of what I say doesn't apply to other OR/M's that's just because I am still wet behind my ears :)
Here are the previous posts:
RELAX AND JUST BUILD YOUR DOMAIN
This is really just a restatement of Part I where I was trying to explain the leap from a relational thought process toward an object-oriented thought process. Simply stated, don't sit down and start with your table structure and then see if your ORM can do it. I have seen myself fall into two traps with this erroneous approach:
-
This results in a disease I am privvy to that I call Tool Malignment Syndrome. Basically, this is when you pick a tool (such as an OR/M) and as soon as you get it you start to write code to make it do things it isn't good at. Just because you might need to do that some day. This syndrome's cousin is Not-Invented-Here.
-
Another syndrome I am prone to...Elaborate Solution Reflux. This is the one that sends someone deep into the bowels of a tool's source-code or API to make it do something that could be solved with a more obvious solution.
I recall writing generic implementations of Custom Types in NHibernate when a Component would have been much simpler and prudent. I learned alot and it has actually been useful on a couple of situations, but the time spent on it may have been better used. This was partly because of my learning curve (I am wondering when that will end) and also because I always was haunted by the "what if..." in programming (YAGNI). A key principle helped alleviate this for me, though, and that is simply writing my domain and pushing back the details of OR/M implementation to support it until the last possible moment. There will definitely be times when i have to write some quick tests to see how NHibernate will accomodate things like complicated queries, but this isn't the driving force behind ANY design decision in my domain. If it were, I'd opt for a different OR/M. This is drawn from the Domain Driven Design camp that insists that the Domain is the driver for the application.
A question came up tonight that had a picture of three tables and then a mapping file that was trying to accomodate the table structure. I realize sometimes this is just the way things are (legacy) but mostly it is just trying to swim upstream. My recommendation over and over is to write your classes, build your API and THEN use the power of your OR/M to represent that in the database. I have noticed that since adapting this style of programming my speed of completing meaningful and useable modules has at least DOUBLED.
Okay...back to work...