Editorials

Micro ORM

Many applications use ORM tools and generators that provide a lot of bells and whistles. The more functionality added to the ORM, the less responsive they seem to become. You’ll find ORMs with Cache, relational mapping, data change migration, repositories, all on top of interacting with the data store. I have an application using Entity Framework that takes a few seconds whenever it initializes, waiting for validation that the database schema matches the ORM code.

For this reason we have seen a number of projects, mostly open source, creating what has grown to be known as a Micro ORM. The ORMs focus on the key aspects of integrating with the data store, with little or no bells and whistles. Many ship as a single file you include in your source code. Some have a complete standalone library. You’ll find Micro ORMs for many different languages. I see Java and Dot Net implementations as some of the most popular, but, I’m sure there are many more that I haven’t had time to find yet.

If you want to use a repository pattern, you build your own, using the Micro ORM for the database communication. In fact, using your own repository implementation can be quite helpful in that you can swap out one ORM for another with little impact on the client code calling your persistence layer.

PluralSight has a nice series of introduction courses on five popular Dot Net ORMs. Dapper, OrmLite, Massive, PetaPoco and Simple.Data each have demonstrations, averaging about 45 min. each.

Some of these Micro ORM libraries are fairly close to the native language, usually SQL, of the storage engine. Others prefer a fluent syntax, with the goal to make persistence more intuitive to developers, giving database power without the SQL learning curve. If you are already comfortable with SQL, you migtht prefer something more like PetaPoco which has some close SQL heritage in it’s syntax.

There is a bit of a controversy when it comes to ORM tools. Should it be Domain Driven or Data Driven in design? Should it use a fluent syntax, native SQL, or some combination of the two? Is the goal to keep it small, or to make it fast performing? What about the features I’m not getting if I use a Micro ORM?

What’s you take? Time to leave a comment if you want to get into the conversation.

Cheers,

Ben