The three reasons to use an O/RM
- Type security
- Data copying Entity/Recordset
- Faster turn around with a moving schema
If these 3 issues aren’t a problem in you case, be reluctant to use an O/RM as an O/RM brings a bunch of other problems.
Type security
When you get the Customer.Verified out of a database the code already knows it is a boolean. No explicit type casting or declaring is needed as it is done elswhere, once and for all.
Now this isn’t totally true but depends on whether LINQ or HQL (or for another O/RM) you are using. But basically it is true, because of solid Right-left copying
Right-left data copying
Copying data from a recordset to the Entity is done by the OR/M and configured once and for all. Unlike a programmer it won’t forget to copy a field in an obscure corner in your code base.
It isn’t hard to write a data copying function for this simple case and dragging a whole OR/M into the project is a lot of dependencies for little use.
Turn around
When the scheme is changing fast, like in the beginning of a project, or when prototyping, an O/RM is of great help to change in one place and let the coding tools and compiler do the rest of the changes in the project.
Schemes tend to solidify after a while and only change in small increments so speeding up the first 3 months for having a rucksack the coming 6 years might not be the best solution.
Tags: entity framework, hibernate, llblgen, nhibernate, O/RM