If you have anything to do with development, you have
probably heard about “Object Relational Mappers”, or ORMs before. There is a lot of information available on
what they are, but most are overly technical, not objective, or both. So for those of you who aren’t directly
involved in writing code, here’s my attempt at describing the purpose and use
of ORMs.
ORMs are essentially tools to allow developers to map
information in a database to classes in the business logic layer with a
relatively small amount of effort. The
productivity gains can be significant, since some ORMs help the developer
create objects, data access code, and update code easily after a database
change. From a developer’s perspective,
ORMs can be handy because they can effectively translate between the tabular
database storage model to “objects” that exist in code.
Despite their uses, ORMs have a lot of detractors within the
programming community, especially with some of the more skilled open source
developers. Actual complaints vary, but
the gist of their arguments is that these tools don’t generate objects or data
access code that operate as efficiently as can be. The code generated does not meet their
standards of quality, and therefore they argue ORMs should be shunned.
Since most developers do not have unlimited time, I’d
suggest using some sort of ORM whenever practical. The productivity gains will far outweigh
performance hits for the vast majority of situations. I would agree strongly that ORMs do not
generate the most elegant code, but that is a necessary trade-off that needs to
be made to get useful functionality.
Remember, just because something does not meet your internal standards for quality doesn’t mean that it isn’t good enough for the customer. Finally,
don’t be afraid to look at different ORMs.
Choosing the wrong ORM can cause problems for the developer and increase
costs in the long run. Choose the right
one (or at least an adequate one), though, and your productivity (or your
developer’s productivity) should increase significantly.
No comments:
Post a Comment