In my previous post I talked about story of ORM & ME. That may show that I'm fond of ORM, and I do.
But, my humble opinion, there is unsaid fact that ORM is not suitable for every time & every project.
It happened that I worked for an employer who has a mission-critical system that integrates with other e-government solutions. System was running fine & business was going on. But from point of view of a developer this system was a nightmare. No one will be happy to touch a Web Form. Where's the problem? The system didn't have a Domain Model and didn't have the right analysis & design.
It's a set of classes, or actually helper classes, and forms that retrieve data from database & push it to screen and back to database. Most of business was in database too. That forced me to avoid introducing ORM to the team because that meant we have to re-design the application from scratch; sure that wasn't an option.
Why this system wasn't suitable for ORM? Because It doesn't have proper OOA&D.
It has no entities or real classes with clear responsibilities. Real classes or entities must satisfy the Single Responsibility Principle. Real domain model mustn't be anemic.
It's vital for every developer and designer to understand the GRASP very well.
These concepts are basics of OO programming which precedes the topic of ORM by few light-years.
Those names are not fancy names to talk about, those words embed great knowledge inside.
From here, my passion for Domain-Driven Design, DDD, starts, I love it but I couldn't master it yet :)
But, I'm working on. I understand that the better I understand my domain, the better I design my solutions, the closer I'm to DDD ;)
Currently, I work on solutions that don't use ORM and I can't use my favorite tool; NHibernate.
But I don't feel bad about this as long as I build them properly, as much as I can.
According to DDD, there is not a condition on my Repositories to read from Stored Procedure or from NHibernate Session. What matters is to design a right domain model & extract right entities & value objects from problem domain.
Let's coin those statements as we didn't in previous post.
1. ORM is not a must but analyzing your problem domain & designing proper solution is.
2. ORM is suitable and flourishing approach when you have a rich domain model; which's related 1.
3. Good designs save time even If took long time to figure it out.
4. We don't build systems for the first-time only; think of maintenance & next version.
5. Finally, my favorite, Copy & Paste is good for writing but NEVER use it for programming.
At the end, my word for my fellow developers, specially in Middle East, Knowledge is available run after it, It deserves to dedicate much time, if you chose to be a Software Developer.
And..... Wikipedia is a Treasure :D