ORM Anti-pattern – Right conclusion, wrong reasons – Rebuttal

ORM Anti-pattern – Right conclusion, wrong reasons – Rebuttal

This is a rebuttal for Right conclusion, wrong reasons  (http://bit.ly/oULuaz ) for an ORM being an anti-pattern.

The main purpose of an ORM (Object Relational Mapper) is to fix the object-relational mismatch, which is a mismatch between how an object is treated differently by the object oriented and relational paradigms which are fundamental constructs in programming and data storage/retrieval. The mismatch is well addressed by Scott Ambler of the Agile Manifesto (http://www.agiledata.org/essays/impedanceMismatch.html), Jeff Atwood of Coding Horror (http://bit.ly/pbImtX).

The traditional waterfall method handles this problem by trying to identify all entities and relationships before development begins. However the Rational Unified Process (RUP), Scrum and other agile development methods, however face a problem in that the data model changes, drastically during development, as more information becomes available and the client/implementation team learn more about the solution and business needs.

Hard-coding SQL statements becomes critical as these changes are not easily reflected as the database model evolves. ORMs like Hibernate (http://hibernate.org/) and Doctine (http://www.doctrine-project.org/) provide a means of mapping the POJOS (Plain Old Java Objects) and POPOs (Plain Old PHP Objects) into relational tables via XML mappings, and annotations (depending on your needs). As your model changes rapidly, all u have to keep changing is the database schema and object definitions.

The major strengths are also a big weakness, ORMs generate generic SQL which is not very optimized, so is slow when using traversing the object graphs, however a mix of ORM access (content pages, display pages where most attributes are displayed) and straight SQL (for lists and pagination) tends to reduce the impact of a the problem.

I have no experience in the new NoSQL data stores so I do not know what the implications are, but ease of unit testing, tool support etc, save time especially when the changes are rapid 🙂

8 thoughts on “ORM Anti-pattern – Right conclusion, wrong reasons – Rebuttal

  1. Heheheheh Have you ever heard the phrase, “the vietnam of programming”? If you saw the app I am writing, you would curse ORMs and long for NoSQLs like RavenDB and others. Other than the optimisation problem, there is the querying problem that makes people add LINQ eg linq to nhibernate and such like.
    I personally use XPO by developer express and Nhibernate. But even as I do, I do so knowing that this is Nam and that “charlie” (bad coding and bugs) can ambush me at any twist or turn.

    1. The key approach is that use ORM for persisting objects including business rule enforcement, thick model fat controller paradigm, and then use straight SQL for lists, queries and pagination

      Object oriented has its strengths and its weaknesses, LINQ is like Hibernate NQL (hope I got it right) and Doctrine (DQL) they bring back objects, but u do not always need objects

  2. Thanks… This is a good post.

    For pagination you can still use your ORM if its ‘clever’ and uses IQueryable. The Skip/Take is taken care of automatically.

    Besides the one I wrote, I personally like DataObjects.NET (http://dataobjects.net).

    For reporting/BI I normally have a replicated server which uses raw SQL and reporting services.

    1. I am a PHP guy, but I would try out of stay out of ORM “smart” links since invoking the ORM is a heavyweight action call based on experience from Doctrine and Hibernate, dunno about Ibatis.

Leave a Reply

Your email address will not be published. Required fields are marked *

Back To Top