Which ORM should I use instead of Linq to Sql?

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 s开发者_运维技巧imply 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!

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.

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.

I would say that NHibernate + FluentNhibernate would get you up and running very quickly. The best thing about FluentNhibernate is that you can set it up in just a few lines and it'll automatically map your objects to your database for you.

If you want something that's a little lighter on the config you might want to check out Subsonic

Have you seen S#arpArchitecture? It's a framework based on NHibernate and ASP.NET MVC, on which you can build your application.

Well, if you intend to build everything from scratch (maybe to learn about architecture), you can take a look at S#arpArchitecture's source code to get some inspiration.

I would agree with you in picking up the second option. Not because i know that the performance in this case is better, but because you said that you want to have a well architect-ed system. In case you use LINQ to SQL the problem you would face is that the classes you would be generating using LINQ drag and drop would be depending strongly on the schema of your database and your table structure. Anytime you make a change in your table structure you will have to regenerate the LINQ classes. This is not desirable from the point of view of a good architecture. You should consider using NHibernate with asp.net mvc. NHibernates provide you the power of mapping your business object properties with your database table fields via xml file. This adds an additional layer of abstraction where in your business entities don't directly depend on your table structure. There is a good project on codeplex that uses NHibernates. Here is the url for that project http://jscportal.codeplex.com/ . This is a very clean CMS portal built using asp.net mvc and NHibernates. Also this project will give you an idea of making a good design for your application. All the best !

Well my vote would be, before going down the ORM route, check out a fully fledged OODBMS as well.

db4Objects from Versant is definitely worth a look, its fast, its ridiculously easy to use and its quite Mature.

Edit: Note, db4Objects supports Linq as well.

since this is project is for learning purpose use Nhibernate it is really worth the effort to learn :)

LLBLGen Pro is simply the best