Things you will love about MicroORM's
If you've worked with ORM's, I'm sure you've run into a few headaches -- query tuning, managing sessions (using evict correctly!), performance overhead, etc. These frustrations might drive you back to relying on stored procedures. Stored procedures can be a good option, but I wanted to highlight MicroORM's as an in-between step, allowing you the flexibility of writing your own SQL, while still removing much of the boilerplate code. The idea isn't totally new -- there have been thin ORM's such as MyBatis around for a while, but there has recently been a new wave of popularity due to several new MicroORM's for .NET.
Here are a few things I really like about MicroORM's
1. Control, control, control -- write that query the way you want to to use that clustered index and be really fast. It's easier to write queries yourself if you require a lot of complex joins, subqueries. HQL and EntityFramework offer ways to do joins being able to write your own SQL for better performance can save a lot of time reading documentation and ORM code to find a solution.
2. Simple, simple, simple -- unadulterated POCO's (most of the time -- see below), the query you write is what you get, etc.
3. Speed -- they are faster than traditional ORM's because they're leaner. Most of them are a few thousand lines of code, total.
4. Better integration with legacy apps -- no more fighting with an ORM to work smoothly with old, lousy data structures, because you can write your own SQL. It doesn't fix the lousy data structure, but makes it easier to interface with it.
Don't get me wrong -- I think big ORM's still have their place. For example, a large, complex web application might want the flexibility of an ORM to offer first- and second-level caching, event listeners, and query filters, as described in a previous post. There is flexibility around caching providers, to fit with your cache of choice. If you don't have a lot of complex queries and really just need to do simple CRUD, a big ORM can be a good fit.
A Comparison -- Dapper and PetaPoco
I recently was tasked with a technology selection for a new service with a small, simple database. We knew the schema wasn't going to grow much, but there would be complex queries and potentially a large volume of data. That meant query performance was important. NHibernate had been used on other applications, but we thought it might be overkill for this app. We decided to evaluate a couple of MicroORM's -- Dapper and Petapoco. Here's an overview:
Dapper
- Support -- It was open-sourced by StackOverflow, and they use it in production. That's a good sign for its speed and stability.
- Simple Purpose -- It's a query engine. That's all -- no inserts, updates, and deletes out of the box. This allows for totally clean POCO's, but means you write a little more SQL. A trade-off. Full CRUD capability is available in an extension.
- Test cases -- Dapper comes with a rich set of test cases that act as excellent "documentation" of how to use it.
- Generated Classes -- Classes can be generated from a T4 template.
Petapoco
- Rich Feature Set -- Petapoco has a richer feature set than Dapper -- full CRUD capabilities out of the box, as well as paging queries and IsNew.
- POCO Attributes -- The additional features often mean you need decorate your POCO's with attributes. For example, in order to do Insert, Update, and IsNew, I had to include a table name and identity key attribute. This may be a turn-off for the purists who really want simple POCO's.
- Generated Classes -- Like Dapper, classes can be generated from a T4 template.
In the end, Dapper was the better fit for our application because we didn't need the additional features, and we liked the fact that StackOverflow stands behind Dapper. You might find that Petapoco or another MicroORM might be best for your situation!
