Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I'm looking at evaluating ORMs.

I've used SubSonic, Linq-to-SQL and Entity Framework. I've got a team of developers ranging from juniors to seniors.

What are the criterias for evaluating an ORM for.NET?

share|improve this question
8  
There is no best. There are a lot of options that have a set of pros and cons. Each bring something different to the table. –  Tony Oct 5 '10 at 13:09
    
One contention on terminology: I would say SubSonic is most certainly not an ORM. More of a .. relational-to-object exposer. It can only generate classes that directly reflect your database table schema. It works fine for the most part, but this design point is quite important as it is on a very different playing field from EF & NHib. –  qes Nov 12 '10 at 20:17
1  
@qstarin: that makes SubSonic as much an ORM as LINQ-to-SQL. –  John Saunders Jan 8 '11 at 23:19
    
very good point, John and qstarin. its a fine line what you'd categorise as a relational-to-object exposer. SubSonic 3.0 offers features which are inline with the concepts of ORM. Wiki says. "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." furthermore on ormbattle.net SubSonic is regarded as an ORM. Thank you both for your feedback –  Nickz Jan 9 '11 at 23:44
2  
I see Linq-to-SQL more like a glorified sql generator than an ORM... –  fretje Apr 1 '11 at 10:04
show 1 more comment

13 Answers

up vote 41 down vote accepted

It's a loaded question.
There are lots of very good ORMs approaching the subject with different philosophies.
None are perfect through and all tend to become complex as soon as you stray from their golden path (and sometimes even when you stick to it).

What you should ask yourself when selecting an ORM:

  1. What does it need to do for you?
    If you already have a set of requirements for your application, then you should select the ORM that better matches these rather than an hypothetical 'best'.

  2. Is your data shared or just local?
    A lot of the hairiness in ORM is caused by how they handle concurrency and changes to the data in the database when multiple users are holding a versions of the same data.
    If your datastore is for a single-user, then most ORMs will do a good job. However, ask yourself some hard questions in a multi-user scenario: how is locking handled? What happens when I delete an object? How does it affects other related objects? Is the ORM working close to the metal of the backend or is it caching a lot of data (improving performance at the expense of increasing the risk of staleness).

  3. Is the ORM well adapted for your type of application? A particular ORM may be hard to work with (lots of performance overhead, hard to code) if it's a used in a service or sitting inside a web app. It may on the contrary be great for desktop apps.

  4. Do you have to give up database-specific enhancements?
    ORMs tend to use the lowest-common denominator set of SQL to ensure they work with lots of different database backend.
    All ORMs will compromise on available features (unless they specifically target a single backend) but some will allow you to implement additional behaviours to exploit specific enhancements available in your chosen backend.
    A typical db-specific enhancement is Full-Text search capabilities for instance; make sure your ORM provides you with a way to access these features if you need them.

  5. How does the ORM manages changes in the data model?
    Some can update the DB automatically within a certain measure, other don't do anything and you'll have to do the dirty work yourself; other provide a framework for handling change that lets you control database updates.

  6. Do your mind to couple your application to the ORM's objects or do you prefer to handle POCOs and user an adapter for persistence?
    The former is usually simple to handle but create dependencies on your ORM-specific data objects everywhere, the latter is more flexible, at the cost of a bit more code.

  7. Will you ever need to transfer your objects remotely?
    Not all ORMs are equal when it comes to fetching objects from a remote server, look closely at what is possible or impossible to do. Some are efficient, others not.

  8. Is there someone you can turn to for help?
    Is there good commercial support? How big and active is the community around the project?
    What are the issues existing users are having with the product?
    Do they get quick solutions?

A few ORMs that I looked at:

  • XPO
    From developer Express: is small and simple, code-centric. They use it for their application framework eXpressApp.
  • NHibernate
    Is free, but the learning curve is rather steep. Lots of goodies but it's hard to find what is really relevant sometimes in all the fragmented documentation.
  • LLBLGen Pro
    very mature project, not the simplest but a lot of thought has been put into it.
  • Entity Framework
    GEtting there. The last releases are pretty good and MS is listening, although it's still a bit young compared to other more mature ORMs.
  • DataObject.Net
    Looks promising but is also a bit new to risk an important project on it IMHO. Quite active though.

There are many others of course.

You can have a look at the controversial site ORM Battle that lists some performance benchmarks, although you have to be aware that raw speed is not necessarily the most important factor for your project and that the producers of the website is DataObject.Net.

share|improve this answer
3  
Knowing that, what did you pick? –  Steve Evers Oct 5 '10 at 22:52
    
thanks Renaud Bompuis, I haven't heard of some of the listed ORMs. The information you've provided is great food for thought, thanks. –  Nickz Oct 6 '10 at 3:38
1  
@SnOrfus: still using XPO but I going to migrating to LLBLGen, it is solid, mature and you remain in control (so you can still get your hands dirty if you need/want to) and it allows for more adequate separation of concerns and object reuse (through the Adapter). –  Renaud Bompuis Oct 6 '10 at 7:50
3  
It's worth noting that Entity Framework is now at version 4.1 and would certainly now be worth looking at. –  Sean Kearon Jun 5 '11 at 13:44
add comment

I'm using NHibernate and have found it pretty good.

In my case, linked to an MS Sql database, but you can connect to other databases.

It doesn't take long to get up and running - just map your object to the model - I use an xml file but you can do it fluently in code. There's a great community, and personally I have found Ayende's work to be very helpful - I use NHProf which is an sql profiling tool.

I mostly use the out of the box functions - straight object mapping, but I've also use the Hibernate Query Language, which is pretty easy to get a hold of.

share|improve this answer
    
Be careful, NHibernate can be tricky for more complicated models. It's all well documented and makes very good sense, but if you aren't aware you can run into problems. That is to say, the learning curve is high, but it is excellent. –  Matt Olenik Oct 5 '10 at 2:38
    
thanks Sam, I haven't used nhibernate however it appears to require extensive configuration compared to SubSonic, Linq-to-SQL and Entity Framework. This wouldn't be ideal for my development team. –  Nickz Oct 5 '10 at 2:44
    
If you're at all interested, Ayende is giving an NHibernate workshop at the YOW Australia conference - yowconference.com.au/melbourne/events_tracks/… - in November / December. One of the guys I work with used it for a while, so I had the benefit of learning off him. –  Sam Oct 5 '10 at 4:55
3  
@Nick most of the configuration can be automated. I would also check out the fluent add on. –  stonemetal Oct 5 '10 at 18:37
    
@Nick, @stonemetal agreed, Fluent NHibernate makes things much easier. It's not as rapid as SubSonic, but still worth a look. –  Matt Olenik Oct 5 '10 at 21:11
show 1 more comment

Sadly, in my last three jobs, we had three home-grown ORMs. In each case, they mostly sucked for varying reasons.

I have recently been evaluating Entity Framework 4 and its POCO support (a nice walkthrough is here) and am really impressed at how nicely it stays out of my face and makes me feel like I'm programming again rather than herding data.

share|improve this answer
    
I hear u jesse, previous jobs I've been in a similiar position home-grown ORMs. thanks for feedback. –  Nickz Oct 6 '10 at 2:21
2  
Home-grown ORMs always suck. The best ones are always worse than the crappiest public ORMs. –  Jaco Pretorius Oct 7 '10 at 7:37
    
@JacoPretorius There are counter-examples to that ... but "as a general rule" ... –  pst Feb 9 '12 at 21:21
add comment

ORM Comparison and Benchmarks on ORMBattle.NET enter image description here

share|improve this answer
    
thank you, really interesting stuff. –  Nickz Jan 9 '11 at 23:26
    
would you mind explaining more on what it does and why do you recommend it as answering the question asked? "Link-only answers" are not quite welcome at Stack Exchange –  gnat Sep 30 '13 at 20:57
add comment

I like Linq to Sql a lot. It's simple and has a decent designer. However, I hope to end of life it in favor of Entity framework. I would like to be able to leverage the ability to modify the generators so that I can have customized objects.

The biggest benefit that these have over others (in my opinion) is that they are out of the box with VS. This is also a negative in that you are at the mercy of MS (see Linq to Sql).

share|improve this answer
add comment

[DISCLAIMER: I work for DevExpress]

You can see screenshots of typical applications created by DevExpress application frameworks here. This page also contains a very brief review of our products. For more detailed information on why, I suggest you check out respective product pages on our web site.

As for DevExpress XAF and XPO, here is a good explanation on why to choose our application frameworks. Plus, we provide support and documentation, which is also important and worth mentioning. Feel free to contact us in case of any questions.

share|improve this answer
    
I'm still using XPO and I'm glad about the upcoming updates. –  Renaud Bompuis Jun 9 '11 at 10:32
add comment

We use NHibernate + Fluent NHibernate, with Linq-to-Sql on small projects. The reason for this is:

1) (Not the primary reason) NHibernate seems to have a higher "respect" factor amongst developers (is this true?),

2) Compared to linq-to-SQL, nHibernate allows ORM mapping between Db objects and entities which don't map 1-to-1,

3) We haven't extensively compared nHibernate to Entity Framework 4.0 but here's a good comparison: http://ayende.com/blog/archive/2010/01/05/nhibernate-vs.-entity-framework-4.0.aspx

nHibernate does have somewhat of a steep learning curve and its XML maps can be quite verbose, but start with with the Fluent Nhibernate site documentation and work your way backwards.

share|improve this answer
add comment

There isn't a "best" ORM framework because they all have different combinations of strengths and weaknesses and it tends to be the case that if developers choose to focus on making one area better there are other areas that suffer in comparison (code first vs model first vs database first).

There are, on the other hand, a number of very good ones some of which will be a better match to your personal circumstances and philosophy than others.


Edit: For what its worth, I'm currently using Linq to SQL - mostly because its there though partly because it does a lot right for minimal effort and will probably progress to Entity Framework again "because its there" (though similarly there is also a lot about EF4 that's right as well as some stuff that's wrong). The concern, especially with the latter, would have to be performance but for most of my cases that's not a huge issue and the ability to run Dynamic Data and OData from the models (L2S and EF) has considerable benefits for me in terms of "cheap" wins.

share|improve this answer
    
Thanks for your feedback Murph. I agree on "best" ORM. However I’m look to institute such more standardisation. Using one of ORM’s, will help new developer and existing developers in my team. Currently where using everything, subsonic, ADO.net, linq-to-sql and etc. moving between projects and maintenance is becoming more difficult. –  Nickz Oct 6 '10 at 2:32
    
Oh, I have no problem with your search for a most suitable ORM for your use case(s) and I wholly agree with the desirability of asking the question hereabouts. I'm just waging a futile campaign against use of the word "BEST" in stackexchange questions (-: –  Murph Oct 6 '10 at 7:31
add comment

I would advise you to have a look at DevExpress XPO. This along with DevExpress XAF will make life of any developer easy once its learning curve is crossed.

share|improve this answer
    
XAF is based on XPO which is the ORM. XAF itself build's on this and add's the logic and "automatic" UI etc. –  Sascha Oct 5 '10 at 6:21
    
Please explain why you believe DevExpress XAF will make the life of a developer easy. –  user8 Oct 5 '10 at 7:01
    
@Sascha, thanks for your hint. I have corrected my post. –  Yogi Yang 007 Oct 7 '10 at 4:47
    
@Mark, XAF along with XPO works as an ORM as well as UI generator so it becomes easy for a developer to build full functional apps in .NET with minimum coding. –  Yogi Yang 007 Oct 7 '10 at 4:49
    
One comment from my side to XAF: It's a great system for medium complex business logic environments as it speeds up the the development time for those in factors. Downside is, that, at given borders, it's then again very time consuming to extend it. For example hierarchical users (along with logic like teams) and 'a user may only see items of himself and/or his subordinates' isn't supported out of the box. So, XAF has pros and cons it it really needs to be evaluated if it's the right fit for a project - IMHO. But it's definitely a well done foundation if it fits. –  Sascha Oct 7 '10 at 5:26
show 1 more comment

We've had good luck with Entity Framework. Our situation is somewhat unusual, though -- we do data collection for the reporting team, so they actually design the database. We get the DB and then just use EF to generate the data access classes from it. Works great for us, but we just do bulk data loads, so I can't vouch for how well it does in a more transactional environment.

share|improve this answer
2  
Yeah I'm a fan of EF 4 its much better than the previous version. –  Nickz Jan 9 '11 at 23:28
add comment

NHibernate (+ FluentNHibernate) would be the default option for me. It is very flexible, extensible and robust. It's got a huge amount of users and it's very actively maintained. The downside is the steep learning curve.

MindScape's LightSpeed is simple and user friendly, but still fairly flexible and capable. It has a designer surface like L2S/EF and a UnitOfWork implementation.

share|improve this answer
    
MindScape's LightSpeed looks really interesting. –  Nickz Jan 9 '11 at 23:25
add comment

Well, there is no "best" choice but I would say that regular old Linq to SQL meets your needs. It's not a "true" ORM per se, but it's very lightweight and gives you the flexibility to write code without being aware of it, if that makes sense. What I mean is that you can continue writing code as normal, without having to really be aware of Linq other than having the dbml file(s). You can still write abstractions over it, using the Repository or Gateway patterns, and L2S fulfills the main role of an ORM, which is to get around the Object-Relational Mismatch.

Entity Framework is a bit heavy, and while I've only dabbled with it a little bit it's more "in your face" than basic Linq to Sql, but EF is much more of a true ORM than Linq. I would look at all of the criteria you are looking for in an ORM. Is it just because you want to avoid having to write raw SQL or, worse, have hundreds of Stored Procedures? Do you need some extra features that raw Linq to Sql can't provide? You need to answer those questions, but based on your brief requirement ("lightweight and easy to use") I think Linq is slightly easier than something like Subsonic, and is built-in to Visual Studio.

share|improve this answer
add comment

ECO :) It is much more than an ORM while including state machines and executable OCL (namely EAL) supports. There exists a free version with a 12 domain classes limitation which I think should be pretty neat for small projects.

share|improve this answer
4  
It'd be helpful if you explained why. –  user8 Oct 5 '10 at 1:49
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.