Choice of OR Mapper for a new project

Question

Hello!

We are about to start a new project. It will be a group of web aplications with a good number of shared components. It will have up to 50.000 unique users visits per day and It will be some kind of management panel. All projects will be build in asp.net mvc 2 and they will all work on the one SQL Server database.

We've been very into the NHibernate until I found the ormbattle.net website, where performance tests for a NHibernate looks very poor in comparison with other mappers. In this summary I've found library unknown to me before. BLToolkit looks really promising, but there are both - advantages and disadvantages.

BLToolkit has weak community support, very few examples and I don't really heard about someone who used it in a big project. Also it's very lightweight which means that it do not support many-many relations, lazy loading and caching...

On the other hand the performance is really great, and also it has very good Linq support.

In this case I'm between choosing one of those ways:

1. Don't care so much about performance and use Nhibernate or EF or just L2SQL (which one will be better?) and use ORMapper that has mauch more useful functionality.
2. Focus on that great performance, and build some own solution based on this BLToolkit, using this library mainly as a very good base. Probably I don't need caching if I will use actions caching in MVC. Probably I don't need associations as far as I can write good LINQ queries with a join expressions. Probably I don't need lazy loading as far as I will carefully build exact methods that will get from DB all I need.

I'm not searching for a verdict it this case. What I'm asking for is a little discussion, to point me some problems that I did not considered or just sharing some experience with me about using not only BLToolkit but also other or mappers.

Answer 1

BLToolkit is awesome with great community on russian forum, you can easily ask your questions in English, as most of members of this community know english.

Answer 2

Can you create prototypes with a couple different ORMs you're considering, and see if they perform well enough for your needs? You could write some throwaway "performance spike" code, and populate your tables with sample data using the data generator in Visual Studio.

I think choosing an ORM based on the belief that the alternatives won't perform well enough is a premature optimization - unless you've done tests to confirm your suspicions.

Regarding ormbattle.net, here is Ayende's prespective - he's one of the NHibernate developers. This is from a while back, I don't know if ormbattle.net has changed since then.

LINQ to SQL is no longer being actively developed - so if you want to use an ORM from Microsoft, EF would be the best choice.

I personally prefer NHibernate to EF, but the current version of EF does have a more complete LINQ implementation than the current version of NHibernate. NHibernate 3 (out later this year) will have full LINQ support, as well as another type-safe API called QueryOver.

Answer 3

The ormbattle.net webstite can be very miss leading, as different ORM are designed to be used in different ways, so simple benchmarks don’t tell you match.

You have two basic options.

• Choose the design of your system and database schema then find a data access system that works well for it.
• Or choose data access system and design your database schema to work well with it.

E.g If you choose Nhibernate, you will find that Nhibernate experts will use a given style of database schema (and objects). Copy them and you will have the least pain.

The problem is that no ORM copes well with all style of database schemas and you are unlikely to know until a long way into the development of a system what all you data storage needs are, unless you have written another similar system before.

Remember you can always bypass the ORM and use hand written SQL if you find the your ORM is to slow for some updates.

Answer 4

A very open ended question - at the end of the day we listed our requirements / expectations and went from there. Some of the selection criteria included:

• LINQ Support
• POCO Support vs Proprietary / Embedded Entities
• Eager Loading / Lazy Loading
• Allow for custom Sprocs when more power was needed

Some Links http://stackoverflow.com/questions/3187928/best-orm-to-use-with-c-4-0

http://ormbattle.net/

Ayende compares EF4 and NH2.5+ http://ayende.com/blog/archive/2010/01/05/nhibernate-vs.-entity-framework-4.0.aspx

Good luck