To ORM or Not to ORM. That is the question…
- by Patrick Liekhus
UPDATE: Thanks for the feedback and comments. I have adjusted my table below with your recommendations. I had missed a point or two.
I wanted to do a series on creating an entire project using the EDMX XAF code generation and the SpecFlow BDD Easy Test tools discussed in my earlier posts, but I thought it would be appropriate to start with a simple comparison and reasoning on why I choose to use these tools.
Let’s start by defining the term ORM, or Object-Relational Mapping. According to Wikipedia it is defined as the following:
Object-relational mapping (ORM, O/RM, and O/R mapping) in computer software is a programming technique for converting data between incompatible type systems in object-oriented programming languages. This creates, in effect, a "virtual object database" that can be used from within the programming language.
Why should you care? Basically it allows you to map your business objects in code to their persistence layer behind them. And better yet, why would you want to do this? Let me outline it in the following points:
Development speed. No more need to map repetitive tasks query results to object members. Once the map is created the code is rendered for you.
Persistence portability. The ORM knows how to map SQL specific syntax for the persistence engine you choose. It does not matter if it is SQL Server, Oracle and another database of your choosing.
Standard/Boilerplate code is simplified. The basic CRUD operations are consistent and case use database metadata for basic operations.
So how does this help? Well, let’s compare some of the ORM tools that I have used and/or researched. I have been interested in ORM for some time now. My ORM of choice for a long time was NHibernate and I still believe it has a strong case in some business situations. However, you have to take business considerations into account and the law of diminishing returns. Because of these two factors, my recent activity and experience has been around DevExpress eXpress Persistence Objects (XPO).
The primary reason for this is because they have the DevExpress eXpress Application Framework (XAF) that sits on top of XPO. With this added value, the data model can be created (either database first of code first) and the Web and Windows client can be created from these maps. While out of the box they provide some simple list and detail screens, you can verify easily extend and modify these to your liking. DevExpress has done a tremendous job of providing enough framework while also staying out of the way when you need to extend it. This sounds worse than it really is. What I mean by this is that if you choose to follow DevExpress coding style and recommendations, the hooks and extension points provided allow you to do some pretty heavy lifting while also not worrying about the basics.
I have put together a list of the top features that I have used to compare the limited list of ORM’s that I have exposure with. Again, the biggest selling point in my opinion is that XPO is just a solid as any of the other ORM’s but with the added layer of XAF they become unstoppable. And then couple that with the EDMX modeling tools and code generation, it becomes a no brainer.
Designer Features
Entity Framework
NHibernate
Fluent w/
Nhibernate
Telerik OpenAccess
DevExpress XPO
DevExpress XPO/XAF plus Liekhus Tools
Uses XML to map relationships
-
Yes
-
-
-
Visual class designer interface
Yes
-
-
-
-
Yes
Management integrated w/ Visual Studio
Yes
-
-
Yes
-
Yes
Supports schema first approach
Yes
-
-
Yes
-
Yes
Supports model first approach
Yes
-
-
Yes
Yes
Yes
Supports code first approach
Yes
Yes
Yes
Yes
Yes
Yes
Attribute driven coding style
Yes
-
Yes
-
Yes
Yes
I have a very small team and limited resources with a lot of responsibilities. In order to keep up with our customers, we must rely on tools like these. We use the EDMX tool so that we can create a visual representation of the applications with our customers. Second, we rely on the code generation so that we can focus on the business problems at hand and not whether a field is mapped correctly. This keeps us from requiring as many junior level developers on our team.
I have also worked on multiple teams where they believed in writing their own “framework”. In my experiences and opinion this is not the route to take unless you have a team dedicated to supporting just the framework. Each time that I have worked on custom frameworks, the framework eventually becomes old, out dated and full of “performance” enhancements specific to one or two requirements. With an ORM, there are a lot smarter people than me working on the bigger issue of persistence and performance. Again, my recommendation would be to use an available framework and get to working on your business domain problems.
If your coding is not making money for you, why are you working on it? Do you really need to be writing query to object member code again and again?
Thanks
