Hi,
What percentage of your total development effort do you spend on implementing and maintaining simple Create, Read, Update and Delete (CRUD) methods in your data access layer?
Does moving to an ORM like Hibernate or Entity Framework lead to significant savings? Are there any design smells which let you know when moving to an ORM for your data access layer is a good choice?
Kind regards, Ashish
Having recently spent ridiculous numbers of hours (probably on the order of 40%) duplicating what an ORM would have done in minutes, I have to say that whenever you can allow well tested frameworks to generate (and maintain!) basic CRUD operations, LET IT DO IT!
Let the framework do that at which it excels. Spend your time on the part of the application that really adds value, the business problem you're solving. Only when the framework falls short should you really consider working around it. 'Falling short' could include performance, but generally there are "hooks and knobs" within the framework to let you do what you need to get done.
Implementation/Design Smell: When you've coded the 'StoredProcedureWrapper' for the 40th time or are implementing caching for query results by capturing DAO output, you coulda/shoulda used ORM
With a Ruby/Rails or Groovy/Grails type of framework, I can't see a real reason NOT to start with the ORM layer, as both environments generate the Domain for you.
With Spring/Hibernate, it is a little more complicated, but still saves a lot of hand-coding of very similar small classes.
I've also found in several projects in the last 10 years or so that if we didn't start using an ORM, we ended up developing or 'stealing' JDBC frameworks or other scaffolding code that again duplicates a lot of what an ORM can get you.