Is it still benefitial to think about NHibernate for .Net while there is LINQ to SQL possibility?

I am not very familiar with both LINQ to SQL and NHibernate.

As far as I understand LINQ to SQL is a kind of replacement of NHIbernate for .Net in many ways.

So does this mean that LINQ to SQL is a built-in replacament of NHibernate which let's a .Net developer to skip NHibernate and 开发者_StackOverflowstart to work with LINQ to SQL?

Thanks

NHibernate is much more mature and powerful that either Linq2Sql or EF. In any case, it's useful to know both NH and EF.

This is highly controversial, but I've yet to see an ORM tool which can compete with NHibernate. Granted, LINQ to SQL has strong points -- major one being actual LINQ -- and it's perfectly fine for some purposes, it just is not as flexible and powerful.

Instead of using the word "replacement" use the word "alternative".

So yes, it is an alternative to NHibernate, however, as with most things, it is worth looking at all of the features of both when deciding which route you wish to take.

ummmmmmmmmmmm, they are quite different.

Linq to sql is just a translator from linq to sql, it has not any context, cache and all the nhibernate stuff.

nhibernate compares better to entity framework.

but linq to sql is very light, stackoverflow uses it :).

NHibernate is definitely a great alternative. At the moment, it's still the most powerful ORM in .NET field.

Personally, I'd prefer Entity Framework. It's not yet as powerful as NHibernate but it's Microsoft's tailor made ORM which provides best integration with other MS tools. (E.g. next version of Reporting Services will support EF models.)

They do not compare. LINQ to SQL is not an ORM. However, I believe NHibernate to be the best ORM out there, far outweighing Microsoft's Entity Framework.

1. It seamlessly integrates with pretty much any database engine out there (MS SQL, Oracle, MySQL, SQLite, Firebird, PostgreSQL, etc), something which currently EF does not do maturely and in a manner I would trust within my large-scale applications.
2. By learning it, not only are you implemented a robust and mature solution (remember its Java tried and tested code base) but you are also acquiring knowledge that can be easily applied Java's original Hibernate.
3. I may be speaking out of my mind here, but I don't think EF (again, I'm not even comparing it to LINQ) is currently half as customizable as NHibernate.