Orm Mapping

Micro ORM vs ORM

I have to use Micro ORM for one of my projects recently and want to share my experience with such micro ORM as Dapper or Peta Poco, as well as compare them with such ORM tools as EntityFramework or NHibernate.

When talking about micro orm it usually does not matter which one to use, the differences are usually very small. The most popular is Dapper, from StackOverflow, it also the fasters of all existing. Peta Poco is similar to Dapper, but make you to write less SQL because of using attributes on your model.

When talking about full featured ORM, it's usually Entity Framework or NHibernate. Both works well and easy to use.

You probably already know what is the Micro ORM, but if not: Micro ORM is a lightweight ORM, usually limited in features, but performing faster than full featured ORM. It means than MicroORM suppose to do the same job of mapping table to object, but it sacrifice number of features to have a better performance.

What are the limitation of Micro ORM?

From my experience you can live with some limitation for micro orm, but some can stop you from using it in favor of full featured ORM tools. Below you can see most important limitations of Micro Orm:

  • Caching: Second Level Cache is not supported, so if you need it, you have to implement some kind of database caching yourself. Frankly speaking it's not a huge limitation and it's very easy to solve it just applying .NET caching mechanism.
  • Relationships: there are no one-to-one, many-to-many relationship supported, which means, when you load object from database, all related objects will not be automatically loaded or saved, if you want to load related objects, you have to construct your query special way. This limitation is very annoying, you can still load parent/child object, but you have to construct your SQL query special way or do multiple queries, also when saving parent, you should not forget about children. For me this was one of the reasons switching from Micro ORM tools
  • No designer: most of existing ORM usually have nice designer, where you can create your model, set relationship between objects (a good example Entity Framework), micro ORM does not support it, you should code all your models and relationship. In fact it's not a big limitation at all, for example NHibernate does not have designer as well (at least free designer), but it's extremely easy to setup your model and mapping.
  • Migration: most of ORM tools support some kind of migration or code first approach, where you design your model and after executing application database objects created based on model, and when you make changes database updates as well, this feature is not supported by Micro ORM, you have to use 3rd party tools to do migration. It's not a huge limitation, but have another tool to keep track of changes to your database will require additional efforts, FluentMigrator doing this job pretty well if you need such tool.

What are the benefits of Micro ORM?

In fact there are only two benefits of Micro ORM comparing to ORM, first is simplicity and second is great performance.

Simplicity of Micro ORM

If we take any of existing ORM tool, we will find a hundreds of features, which developers of this ORMs are developed during years of it existence. But usually when we using this tools we use just a small subset of the ORM framework, in most cases we even don't know what are most of the features of the big ORMs. But all this complexity is hurt performance of ORM as well as makes it much more difficult to understand and learn for new developers.

What Micro ORM are doing they provides only features which should exists to make it work, usually it's read from database feature and mapping feature. As a result of such simplicity file size of Micro ORM is very small, and when developer need to look how micro ORM works it's very easy for him to do it and does not require a lot of efforts. For example whole PetaPoco framework takes just a single file with around 4000 lines, where most of the lines are comments. Also Configuration is much more easy and simpler: MicroORM does not require any configuration and in general are easy to use, for example EnttiyFramework require whole section in web.config where you can change behavior and settings of EF, for example in code-first approach it can automatically create new database for you each time model is changed. On the other side Micro ORM require zero configuration, the only required setting is connection string which used to open connection, and you can start using it, this is example how dapper is ready to work with connection using Query<T> extension method, that's it, you add reference to Dapper using Nuget and immediately can use it in your database layer.

Micro ORM performance comparing to different types of ORM

Method Duration
Hand coded (using a SqlDataReader) 47ms
Dapper ExecuteMapperQuery 49ms
PetaPoco 52ms
NHibernate SQL 104ms
Entity framework 631ms

As you see the fastest is Dapper, which provides similar results as SqlDataReader class. When comparing full featured ORM tools the fastest is NHibernate, but still it's 2 times slow than Dapper. Entity Framework is one of the most slow ORM tools, so you probably should not use it for project where performance is #1 priority, but because it's easy to use and it is from Microsoft you can still consider using it.

So what to choose?

After working with all of the mentioned ORM or Micro ORM tools I found than Micro ORM can be used in the following scenarios:

  • Performance: you have a requirement to produce the best possible performance when working with data layer. This does not mean than you believe you need best performance, it means your performance tests tells you than database is bottleneck or your users complain about it AND you can't improve performance another way, for example caching.
  • You doing test/throw away application: if you need to quickly test some concept, you don't want to spend time on application, sure, Micro ORM will help you, it's very fast to develop prototypes.
  • Legacy code working with SqlDataReader: if you already have a code working with SQLDataReader, using Micro ORM will improve your code style and readability with minimum changes to the code, this is especially true if you choose Dapper with it's extension methods applying directly to IDbConnection

You should NOT use Micro ORM

  • You plan to work and support application for a long time (stackoverflow is a huge project exist for a long time, so I may be wrong): it's a pain to work with Micro ORM in medium or big project, especially if repository is complex, for example, your repository contain dozens of methods (GetById, GetByName, GetBySomethingElse).
  • You need to use relationships: it's possible to load relationship for your object (you just construct your SQL query special way), but it's a pain, Micro ORM works well with single object, which maps to your single table, anything more than this give you troubles.

From my experience, I can suggest to use Nhibernate (Personally I prefer NHibernate) or Entity Framework in 99% of your cases , it's simple to use, easy to configure, support all features which you need (and much more which you don't). It may be a little slow comparing to Micro ORM, but do you really need this performance? Unless your clients complain or you performing within your SLA, you don't. And in most cases performance can be improved just be doing caching or refactoring your code. In my case I have to rewrite all data access layer from Dapper to Nhibernate, it solved all my problems, and can't suggest Micro ORM until you 100% sure you need to use it.


Yaplex - Freelance developer - white logo on black background

Yaplex is a custom software development company co-founded by full-stack .NET Software developer Alex Shapovalov who lives in Mississauga, ON and provides software development services in Mississauga and GTA.

Contact Information

Mississauga, ON, Canada
Phone: +1 647 328 3809
Email: alex@yaplex.com