Abstracting your ORM is a futile exercise
Posted at 08:00 on 03 March 2011
The repository pattern is popular in a lot of .NET applications. In most cases, it is implemented as an abstraction layer around NHibernate “just in case” you want to replace it with Entity Framework.
Why on earth would you want to replace NHibernate with Entity Framework?
If you suggested something like that to a Java developer, or a Python developer, or a Ruby developer, they would think you were completely out to lunch. People simply do not abstract out the Django ORM “just in case” they might want to replace it with SQLAlchemy. Or Rails’ ActiveRecord to replace it with DataMapper. Or Hibernate to replace it with iBatis. They pick one or the other and stick with it.
There are four reasons why it’s a bad idea to code for this eventuality.
- YAGNI.
- It just adds an extra layer of indirection into your application, which complicates the changes you need to make on a day-to-day basis, and makes your code harder to understand and debug.
- Changes this fundamental generally require a lot of work and a large rewrite anyway.
- Due to differences in the way NHibernate and Entity Framework work, you will either (a) have to restrict your code to the lowest common denominator between them, making it all but impossible to carry out any form of performance optimisation, or (b) implement something so complicated that it’s not worth the effort.
So why do we do something like this in .NET land? I think a lot of it reflects a malaise in the whole Microsoft ecosystem. It’s a fear that Microsoft will replace the solution we’ve picked with their own version, make it the standard, and in three or four years’ time, our library will no longer be supported.
Unfortunately, that’s the way things seem to work on the Microsoft side of the fence. The whole ecosystem is littered with the corpses of dead third-party libraries: ASP.NET charting components, Ajax toolkits, and so on, that were once sold by thriving commercial vendors that have now gone out of business. They’re .NET 1.1 only, and don’t work with .NET 3.5 or 4.0. And because they were commercial products, and were obfuscated using Dotfuscator or whatever, there’s no way of getting the source code.
But NHibernate is open source. It’s widely deployed all over the place. It’s still in active development. It’s a direct port of the de facto standard Java ORM, so you can put Java guys to work on your .NET project with minimal training. For that reason, it’s not likely to disappear into the great unknown any time soon.