If you haven’t come across the concept of a “micro-ORM,” it refers to a currently fashionable category of data mapping tools which take a minimalist approach to mapping between the database and object worlds. Typically the focus is on materializing a data reader row to a class. That’s the key functionality although features do vary. A developer would typically write inline SQL for the query they wish to run. They are fairly simple, and that’s their point — to not have the weight of a fuller featured ORM.
We do get asked by people who have started to hear about micro-ORMs: when would I choose a product like LightSpeed over a micro-ORM? Both address the same basic job of mapping between SQL data and in-memory objects, so why use one rather than the other? So here are some of the times we think you’d want to use a fully fledged object-relational mapper.
1. You’re not Stack Overflow
Stack Overflow has become the ‘go to’ reference site for micro-ORMs. I mean, if Stack Overflow built a micro-ORM to squeeze out the performance they needed, that means they’ve got to be good, right? But I’ll let you in on a secret: you’re not Stack Overflow.
Stack Overflow is a huge site under extremely heavy load. That makes their performance tradeoffs entirely different from most sites or applications. Most developers, as long as they’re not introducing any performance killers, should be focusing on productivity, not on micro-optimising performance. Rather than handwriting SQL and forgoing additional benefits like validation, integrated migrations and many more nice-to-have features to gain the benefits of needing a smaller server farm, most companies find developer productivity is where they can save more money.
2. You’re not building a throwaway app
Some folks feel that it’s quicker to get up and running with a micro-ORM than with a full ORM. And if it’s quicker to get up and running, that means the micro-ORM is more productive than the full ORM, right?
Well, maybe. Some ORMs do require quite a bit of configuration or repetitive mapping. We’d like to think that LightSpeed isn’t one of those. We reckon that with LightSpeed you can be up and running in less than a minute. Plus you can actually gain time by having LightSpeed create the database schema for you, rather than having to jump across into a database tool.
But fair enough, it does take longer to install LightSpeed than to pull down a micro-ORM via NuGet. So if you’re only going to be spending ten or fifteen minutes on your application, then that might be decisive. But for most realistic applications, the productivity benefits of a full ORM rapidly overtake the time savings of running an installer.
3. You want a domain model
A lot of micro-ORMs are just a class for materializing a database row into an object – either to a concrete class, or to an anonymous type. ORMs like LightSpeed, NHibernate, LLBLGen etc offer far more than just object materialization. If you want to express business logic, have validation, etc. then you either want a higher-end ORM or you want to spend your time writing a lot of tedious boiler plate code. And you probably have better things to do with your time than write tedious boilerplate code.
A domain model also pays off when you’re not the only one working on the project. Encapsulating business logic and validation in the domain model ensures that the business rules apply wherever the objects are used — you’re not relying on everyone remembering to apply the latest rules to their bits of the project. That’s one of the reasons we stopped using DataTables in the first place, remember?
4. You like LINQ
Most micro-ORMs do not include a LINQ provider. Most in fact require that you write the SQL yourself. That isn’t in itself a bad thing, it’s just taste and portability concerns and, frankly, most people don’t move database engine anyway. However, a LOT of .NET developers like LINQ. Many, many more than like SQL. Intellisense, compile-time type checking and compile-time syntax checking combine to make you more productive and to catch errors earlier.
And if you like LINQ, then you’ll want an ORM with a good LINQ provider. That means the LINQ actually translates to SQL, not a supposed LINQ provider that actually pulls all of your data into memory and then uses LINQ to Objects — that will throw away any performance gains you thought you’d be getting from the micro-ORM — and then some.
5. Your data usage pattern isn’t dominated by isolated records
There’s some great performance benchmarks out there for micro-ORMs. Unfortunately, there are a bunch of, well, less great ones too — benchmarks that don’t test real world situations.
If you’re going to be guided by benchmarks, make sure that the benchmark you’re using reflects how your application uses data. For example, suppose your application issues multiple queries to the database, some of which could result in the same entity being returned. Most micro-ORMs don’t use an identity map, so they’ll trundle off to the database and materialise a new copy of the entity. Most full ORMs, by contrast, will see that the entity is already in memory, and save themselves the query and/or the materialisation. And, by the way, they’ll give you handy object identity behaviour instead of you having to write code to test if Instance A represents the same record as Instance B. A typical full ORM is built to have a higher level view of how real world applications are built, and can gain significantly on the performance front by performing these optimizations.
Of course, your application may have special performance characteristics that mean a micro-ORM plus custom performance strategies will perform better than a general-purpose ORM tuned for a typical mix of applications. Stack Overflow is a great example — its performance requirements are so extreme that it’s worth the effort of building that stuff in a way that works for them. You have to ask yourself whether your application justifies that custom construction cost.
And one reason *to* use a micro-ORM
Choosing between a micro-ORM and a higher end ORM shouldn’t be a religious decision. There are certainly places where a micro-ORM makes sense — when you don’t need domain logic, you want to work very intimately with the database, the application is very limited or ad hoc in its scope… an example might be a simple bulk data transfer application, where things like an identity map and validation don’t add any value. We use micro-ORMs at Mindscape when they make sense, and it’s given us an appreciation of their value as well as where they come up short.
So what do you reckon? Are these the key points to consider when deciding between a full and a micro-ORM? What are your reasons for using or not using a micro-ORM?