What to Look in an ORM Solution?

March 14, 2011


What to Look in an ORM Solution?

One question that I sometimes being asked is what to look for in an ORM solution or more properly which ORM ORM_thumb[1]is preferable and why. The decision which ORM to choose is very crucial to the project development since after you start developing it will be hard to go back and use another ORM solution. Since there are many ORMs out there, here is a checklist that will help you to evaluate ORM solutions and to pick the one that fits your needs:

  • Basic Features

    • Can handle inheritance & polymorphism

    • Can handle different types of relations (1-1, 1-N, N-M)

    • Supports transactions

    • Supports different SQL operations (aggregation, grouping, ordering)

  • Extended Features

    • Multiple databases support

    • Allows execution of dynamic queries using a query language

    • Data Binding support

    • Stored Procedure and Function support (only if needed)

    • Can handle very big models and databases

  • Flexibility

    • Allows customization of SQL queries

    • Supports Joins and Sub-Queries

    • Supports concurrency

    • Can handle specific Database types (identity, GUIDs, XML…)

  • Ease of use

    • Graphical designer for mappings

    • Auto generation of model classes

    • Generate Database schema (Model First approach)

    • Maintainable (when Database schema changes)

  • Optimizations & Performances

    • Allows Lazy loading

    • Allows Eager loading

    • First level cache

    • Second level cache

    • Optimizes queries

    • Supports Bulk updates & deletions

  • SOA

    • Supports model serialization

    • Allows loading of disconnected objects

    • Supports disconnected state tracking

    • Model objects are readable in other platforms

  • Other things to consider

    • Price

    • Performance

    • Support for multiple platforms

    • Source code provided

    • Enables unit testing

    • Documentation & Support

    • Maturity

    • Vendor stability

This is a suggested list and there are more things to evaluate other then that by it can help you to make the relevant decision.

Add comment
facebook linkedin twitter email

Leave a Reply

Your email address will not be published.

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>



  1. BetimMarch 15, 2011 ב 9:24

    Which ORM actually does have all these features?

  2. naspinskiMarch 15, 2011 ב 16:45

    I can’t believe I am saying this, but I think Entity Framework finally has this as of v4…

  3. Thomas WellerMarch 16, 2011 ב 6:47

    Persistence ignorance ist a must-have to be able to write tests. A stable and efficient test suite for an app replaces the apps original database with an embedded one like SQLite or SQL Server CE, and all that should be necessary for this is to provide the respective connection string in the test suites configuration file.

    If an ORM does not provide this possibility, it’s not recommendable for production. (Btw: EF is NOT persistence ignorant…).

  4. andyMarch 17, 2011 ב 20:49

    Stay away from ORMs. Use a code generator or hand write ADO.NET code to populate objects from Queries and vice versa.

  5. BrianApril 1, 2011 ב 21:04

    Thomas Weller:

    I don’t agree with your reasoning for claiming EF is not persistence ignorant. First off, you *can* switch between different versions/instances of SQL Server by modifying a connection string in a config file.
    In addition, it is very simple to achieve persistence ignorance with EF by creating repository and unit-of-work interfaces on top of EF, as explained in the following link…
    The test suite can then utilize test doubles or mocks, which is actually a much better methodology than relying on an embedded database. Tests will be more reliable than if you introduce the dependency of some special embedded database for testing purposes.
    So, it’s a little extra work to create a couple of interfaces and then concrete implementations using EF, but this is not a big burden at all.