NHibernate vs LINQ to SQL

Question

As someone who hasn't used either technology on real-world projects I wonder if anyone knows how these two complement each other and how much their functionalities overlap?

Answer 1

Can you clarify what you mean by "LINQ"?

LINQ isn't an data access technology, it's just a language feature which supports querying as a native construct. It can query any object model which supports specific interfaces (e.g. IQueryable).

Many people refer to LINQ To SQL as LINQ, but that's not at all correct. Microsoft has just released LINQ To Entities with .NET 3.5 SP1. Additionally, NHibernate has a LINQ interface, so you could use LINQ and NHibernate to get at your data.

Answer 2

By LINQ, I'm assuming you mean LINQ to SQL because LINQ, by itself, has no database "goings on" associated with it. It's just an query language that has a boat-load of syntac sugar to make it look SQL-ish.

In the very basic of basic examples, NHibernate and LINQ to SQL seem to both be solving the same problem. Once you get pass that you soon realize that NHibernate has support for a lot of features that allow you to create truly rich domain models. There is also a LINQ to NHibernate project that allows you to use LINQ to query NHibernate in much the same way as you would use LINQ to SQL.

Answer 3

I'm assuming by LINQ you're referring to LINQ to SQL...

LINQ to SQL forces you to use the table-per-class pattern. The benefits of using this pattern are that it's quick and easy to implement and it takes very little effort to get your domain running based on an existing database structure. For simple applications, this is perfectly acceptable (and oftentimes even preferable), but for more complex applications devs will often suggest using a domain driven design pattern instead (which is what NHibernate facilitates).

The problem with the table-per-class pattern is that your database structure has a direct influence over your domain design. For instance, let's say you have a Customers table with the following columns to hold a customer's primary address information:

• StreetAddress
• City
• State
• Zip

Now, let's say you want to add columns for the customer's mailing address as well so you add in the following columns to the Customers table:

• MailingStreetAddress
• MailingCity
• MailingState
• MailingZip

Using LINQ to SQL, the Customer object in your domain would now have properties for each of these eight columns. But if you were following a domain driven design pattern, you would probably have created an Address class and had your Customer class hold two Address properties, one for the mailing address and one for their current address.

That's a simple example, but it demonstrates how the table-per-class pattern can lead to a somewhat smelly domain. In the end, it's up to you. Again, for simple apps that just need basic CRUD (create, read, update, delete) functionality, LINQ to SQL is ideal because of simplicity. But personally I like using NHibernate because it facilitates a cleaner domain.

Edit: @lomaxx - Yes, the example I used was simplistic and could have been optimized to work well with LINQ to SQL. I wanted to keep it as basic as possible to drive home the point. The point remains though that there are several scenarios where having your database structure determine your domain structure would be a bad idea, or at least lead to suboptimal OO design.

Answer 4

Or you could use the Castle ActiveRecords project. I've been using that for a short time to ramp up some new code for a legacy project. It uses NHibernate and works on the active record pattern (surprising given its name I know). I haven't tried, but I assume that once you've used it, if you feel the need to drop to NHibernate support directly, it wouldn't be too much to do so for part or all of your project.

Answer 5

@Kevin: I think the problem with the example you are presenting is that you are using a poor database design. I would have thought you'd create a customer table and an address table and normalized the tables. If you do that you can definately use Linq To SQL for the scenario you're suggesting. Scott Guthrie has a great series of posts on using Linq To SQL which I would strongly suggest you check out.

I don't think you could say Linq and NHibernate complement each other as that would imply that they could be used together, and whilst this is possible, you're much better off choosing one and sticking to it.

NHibernate allows you to map your database tables to your domain objects in a highly flexible way. It also allows you to use HBL to query the database.

Linq to SQL also allows you to map your domain objects to the database however it use the Linq query syntax to query the database

The main difference here is that the Linq query syntax is checked at compile time by the compiler to ensure your queries are valid.

Some things to be aware of with linq is that it's only available in .net 3.x and is only supported in VS2008. NHibernate is available in 2.0 and 3.x as well as VS2005.

Some things to be aware of with NHibernate is that it does not generate your domain objects, nor does it generate the mapping files. You need to do this manually. Linq can
do this automatically for you.

Answer 6

@kevin

"LINQ to SQL uses the active record pattern"

That is not correct. It's like saying that ADO.NET uses active record, or NHibernate uses active record. They are all data access technologies and do not enforce any particular data access pattern. I personally like to use linq-to-sql with the repository pattern.

You are correct that linq-to-sql does not support complex mappings like NHibernate does.

Answer 7

Something that I find odd about most .NET developers is the constant reliance on the IDE. If there is no GUI tool, these individuals will pitch a technology. The mapping files are not that complicated to start with. When they do become complicated, I doubt that a GUI tool could handle them anyway.

But to the topic at hand, a great benefit of NHibernate is that you can externalize your HQL into mapping files. This effectively removes the details of the data interaction from the code entirely. As a result, you can have HQL gurus create the queries and have Jr Developers uses those queries without having to know the horrific details. To my knowledge LINQ to SQL lacks such a feature.

Answer 8

Two points that have been missed so far:

• LINQ to SQL does not work with Oracle or any database apart from SqlServer. However 3rd parties do offer better support for Oracle, e.g. devArt's dotConnect, DbLinq, Mindscape's LightSpeed and ALinq. (I do not have any personal experience with these)

• Linq to NHibernate lets you used Linq with a Nhiberate, so it may remove a reason not to use.

Also the new fluent interface to Nhibernate seems to make it less painful to configure Nhibernate’s mapping. (Removing one of the pain points of Nhibernate)

---

Update

Linq to Nhiberate is better in Nhiberate v3 that is now in alpha. Looks like Nhiberate v3 may ship towards the end of this year.

The Entity Frame Work as of .net 4 is also starting to look like a real option.

Answer 9

Fluent NHibernate can generate your mapping files based on simple conventions. No XML-writing and strongly typed.

I've recently worked on a project, where we needed to change from Linq To SQL to NHibernate for performance reasons. Especially L2S's way of materializing the objects seems slower than NHibernate's ditto and the change management is quite slow too. And it can be hard to turn the change management off for specific scenarios where it is not needed.

If you are going to use your entities disconnected from the DataContext - in WCF scenarios for example - you're may have a lot of trouble connecting them to the DataContext again for updating the changes. I have had no problems with that with NHibernate.

The thing I will miss from L2S is mostly the code generation that keeps relations up-to-date on both ends of the entities. But I guess there are some tools for NHibernate to do that out there too...