DCSIMG
What to Look in an ORM Solution? - Gil Fink's Blog

Gil Fink's Blog

Fink about IT

News

Microsoft MVP

My Facebook Profile My Twitter Profile My Linkedin Profile

Locations of visitors to this page

Creative Commons License

Disclaimer
The opinions expressed herein are my own personal opinions and do not represent my employer's view in anyway.
© Copyright 2012 Gil Fink

Hebrew Articles

Index Pages

My OSS Projects

English Articles

What to Look in an ORM Solution?

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.

Comments

DotNetKicks.com said:

You've been kicked (a good thing) - Trackback from DotNetKicks.com

# March 14, 2011 11:32 AM

Betim said:

Which ORM actually does have all these features?

# March 15, 2011 9:24 AM

VNX » Blog Archive » ORM decision making checklist said:

Pingback from  VNX  » Blog Archive   » ORM decision making checklist

# March 15, 2011 9:33 AM

naspinski said:

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

# March 15, 2011 4:45 PM

Thomas Weller said:

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...).

# March 16, 2011 6:47 AM

andy said:

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

# March 17, 2011 8:49 PM

Brian said:

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...

msdn.microsoft.com/.../ff714955.aspx

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.

# April 1, 2011 9:04 PM