Which ORM should I use instead of Linq to Sql?

Question

I'm working on a CMS as my hobby project. Because I'm not paid for it, time is not very essential and I aspire to make a well-architected system.

I have a set of business classes which are responsible for the main logic, and they are getting data from a database through interfaces, and the data provider (which sould implement an interface) can be set from configuration.

Currently I use LINQ to SQL as my data access layer, but the more I read about this topic, the more I'm convinced that I should use a more advanced ORM, because LINQ to SQL doesn't support some things that would be very good for the overall performance of the application. For example, caching and persistence. (I read that NHibernate, for example, only consults with the database if necessary, otherwise it simply gets the data from its cache. - This is good, because on average, a website doesn't get new content for days, so instead of wasting performance by reading from the database on every request, it would be just fine to serve those from a cache.)

I'm thinking about some options and would like to know what should I do about this.

1. Write my own persistence logic for my business classes, and keep using LINQ to SQL.
2. Use NHibernate directly, or through Castle ActiveRecord or Fluent NHibernate
3. Use some other ORM

My favourite choice would be the second, because NHibernate is more robust than what I need, and ActiveRecord seems to hide most of the complexity. (And, by the way, I also intend to use Castle Windsor.)

The only problem is, that I couldn't find any information on the performance of these tools. I spent a few hours googling (and binging (and I was looking on this site, as well)), found quite a few articles and blog posts, but none of those said anything about performance.

Will this be better than the current solution, or should I use something quite different for the task?

Thanks in advance!

Answer 1

Linq to SQL is nice (if you won't use anything but SQL Server). Don't bother with Linq to Entities (EF). It's broken (far from matured) - on so many levels.

I'd go for NHibernate myself - great entity mapping and multiple DB platform support. And a very much tried and tested ORM.

Answer 2

I would recommend Entity Framework v4.0. Unlike the first, failed flop of an attempt at an ORM with EF v1.0, the version coming out with .NET 4.0 is truly amazing. Microsoft improved EF on every level, and directly responded to input from many of the major ORM community proponents. I had some direct input via email with Microsoft on several issues with EF, including the efficiency and validity of the generated SQL, n-Tier story, and the visual designer.

The new EF is a solid ORM that provides a complete OOB story for everything from a rich visual designer with customizable code generation, efficient SQL generation, multi-tier portable types, POCO style implementation, very rich mappings between your code, conceptual model, and database schema, etc. I used to be a big proponent of nHibernate and a strong opponent of EF, but my opinion has changed since I started using VS2010/.NET 4.0 Beta 2. I highly recommend using EF v4.0 if you are working on the .NET platform.