I have used 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 makes you write less SQL because of using attributes on your model.
When talking about full-featured ORM, it’s usually Entity Framework or NHibernate. Both work well and are 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 that MicroORM suppose to do the same job of mapping table to object, but it sacrifices a number of features to have a better performance.
What are the limitations of Micro ORM?
From my experience, you can live with some limitations for micro ORM, but some can stop you from using it in favour of full-featured ORM tools. Below you can see the 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 is no one-to-one, many-to-many relationship supported, which means, when you load an object from the 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 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 a designer as well (at least a free designer), but it’s extremely easy to set up 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 the 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 a 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 a tool.
What are the benefits of Micro ORM?
In fact, there are only two benefits of Micro ORM comparing to ORM, the first is simplicity and the second is a great performance.
The simplicity of Micro ORM
If we take any of the existing ORM tools, we will find hundreds of features, which developers of these ORMs are developed during years of their existence. But usually, when we using these tools we use just a small subset of the ORM framework, in most cases, we even don’t know what is most of the features of the big ORMs. But all this complexity has hurt the performance of ORM as well as makes it much more difficult to understand and learn for new developers.
What Micro ORM is doing is they provide only features that should exist 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 the developer needs to look at how micro ORM works it’s very easy for him to do it and does not require a lot of effort. For example, the 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 requires the whole section on the web.config where you can change behaviour and settings of EF, for example in a code-first approach it can automatically create a new database for you each time model is changed. On the other side Micro ORM requires zero-configuration, the only required setting is connection string which is used to open connection, and you can start using it, this is an example of how Dapper is ready to work with the connection using Query<T> extension method, that’s it, you add a 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 the 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 slowest ORM tools, so you probably should not use it for a project where performance is the #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 that Micro ORM can be used in the following scenarios:
- Performance: you have a requirement to produce the best possible performance when working with the data layer. This does not mean than you believe you need the best performance, it means your performance tests tell you than the database is a bottleneck or your users complain about it AND you can’t improve performance another way, for example caching.
- You do a test/throw away application: if you need to quickly test some concept, you don’t want to spend time on the 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 its extension methods applying directly to IDbConnection
You should NOT use Micro ORM
- You plan to work and support an 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 a medium or big project, especially if the repository is complex, for example, your repository contains 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 a single object, which maps to your single table, anything more than this gives you troubles.
From my experience, I can suggest using 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 by 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 are 100% sure you need to use it.
Alex Shapovalov is an independent contractor and founder of Yaplex – a Canadian custom software development company. Alex is a seasoned full-stack Software Developer who provides software development services in Canada and the USA.