All of us know that every project has its own requirements and hence need
its own solutions, technologies and frameworks. Choosing technologies for
every project should depend of factors such as requirements, maturity and
team's experience. Database access technology follows the same role.
Bellow I refer to some points showing why brokers out perform ORMs. To be
fair, I have also tried to point to the circumstances where ORMs are
better alternatives.
Please note that these are my own comments. Other friends might have other
(and maybe more correct) points which are fully respected. I'm not
interested in starting a war by any means but simply refer to some of my
own experiments. Any comments are welcomed...
1. iBATIS has a very short and fast learning curve. All you need to know
is SQL (which you already know :). Believe it or not your team can master
iBATIS SQL Map in less than an hour. Tell me how much is the same for an
ORM ?
2. Nowadays databases are very strong on performing data access logic and
ignoring this power wont be wise. While using brokers you can use all
power of your database such as stored-procedures, views, non
SQL-compatible types, casting, ... . On the other side, ORM insist merely
on standards and dumb CRUD behaviors of databases and rarely use the
complete power of DB. Using stored-procedures for example you can do most
of filtering in DB side and save a lot of I/O too.
3. Brokers have less depending on reflection and proxy pattern, hence
enhance runtime and initialization speed.
4. Using ORM you don't have much control over generated SQL command. This
is for example crucial for databases such as DB2 where optimizing queries
have a sensible impact of access path and performance.
5. ORM performance is very dependent on caching object graph, hence it
eventually becomes ineffective for large databases where hit ratio is low.
I am involved in a project where the database has about 600G of data. Even
using the best possible caching schema and most advanced high-end servers
what is your estimation of cache hit ratio ? So much data (end even more)
is normally expectable for real world projects.
6. Against a general believe that ORM does most of the work and reduces
complexity, most of the time ORMs becomes really complex and even advanced
users have to think and discus before they decide how to handle various
cases. Brokers bring simplicity. There is no news of strange and hard to
resolve exceptions and your team is relax.
7. iBATIS supports for caching and lazy loading as ORM (and sometimes even
better).
8. There is no need to define so much XML or annotations for every entity
object. You define as much meta data as you need.
9. Using iBATIS you move more code to data definition. You end up with
less LoC even compared to ORM.
10. MySpace.com (top 5th site on Internet) runs on iBATIS. FYI no site in
top 100 uses ORM.
11. As there is less to learn, there is less to expire. How much change do
we face in ORM world each year? Using brokers you have good old SQL which
is mature since 80s.
12. Read Gavin King's interviews. He himself (as the creator of Hibernate)
accepts that ORMs are not the best choice in some occasion (he points to
huge DBs) and suggest iBATIS.
13. Brokers bring less memory usage (no object-graph caching) and
preventing false and blind pre-fetches. Very effective on low memory
machines. You can save your budget for a better hardware for your
centralized DB (1 machine) not your distributed application servers (N
machines).
14. If you don't accept my words, see which solutions are used in
bootstrap projects such as Equinox. Such projects always try to use the
best practices.
Some computerists believe ORM to be a great mistake in all cases. You
might have heard to refer to ORMs as Vietnam of computation world. I don't
like to face it this way. Like every other technology ORM has it's own
benefits too. According to me ORM is reasonable choices in cases such as:
a. Spread data on many tables. Complex and dynamic DB like ERP, etc.
b. Slow and non optimized DB structure.
c. General purpose products, where you don't want to relay on specific DB.
Atlasian Jira is a good example.
d. Low knowledge on SQL in the team. (very rare)