Which is beneficial for start up; Linq to SQL or Nhibernate?

Question

I want to learn ORM and I wonder which is beneficial for start up; Linq to SQL or Nhibernate. considering time,adaptation... etc

Answer 1

If you don't have experience with ORMs Linq to SQL is slightly easier to learn than NHibernate. It also has better integration with Visual Studio.

Answer 2

Linq to SQL is supposed to be replaced by the Entity Framework; I think NHibernate would be a good choice since there are lots of references and it seems be widely used as well.

Answer 3

In addition to Darin answer, Consider this post i read earlier.

Linq to SQL is easier and faster to implement and integrate quickly, but Nhibernate can give you more flexibility if you need more control. Recently, i had to decide if i was to use Linq to SQL on my new app project - i just didn't like the lack of flexibility.

http://stackoverflow.com/questions/26971/nhibernate-vs-linq-to-sql http://www.acceptedeclectic.com/2007/12/linq-to-sql-vs-nhibernate-part-1-what.html

Let me know if it helps.

Answer 4

I'd go with NHibernate, because there's a nice open source community out there that supports it, answers questions on it, and so on. As your product gets bigger and more complicated, you'll appreciate the power and flexibility of NH. Finally, Linq-to-sql isn't in MS's long term plans, since they want you to use the Entity Framework, so you might end up with a dead-end technology there.

Answer 5

One important question to ask yourself is if you can accept a dependency on SQL Server. Will the database backend change to Oracle, for example? LINQ to SQL is strongly coupled to SQL Server, whereas NHibernate isn't. I'm not saying that this is necessarily a bad limitation, but it's important to consider.

NHibernate has really come a long way in the past few years. I really like Fluent NHibernate, for example, but that's not to say that LINQ to SQL is limiting. I love the integration with Visual Studio and it has proved itself more than capable of handling consistent load (Stack Overflow uses LINQ to SQL, for example).

Contrary to popular belief, LINQ to SQL is not dead.

Edit: Another important question to ask yourself is if you want to change the domain model. LINQ to SQL maps objects directly to tables. NHibernate, on the other hand, allows for a layer of indirection. This is also true of Entity Framework, by the way.

Answer 6

I would put in my vote for Linq-to-SQL - why?

• it has a visual designer which allows you to more easily and quickly get results and see something
• NHibernate is very powerful - but that also makes it harder to learn; you have to really really love angle bracket soup (i.e. lots of XML mapping files) to get up to speed with NHibernate

Answer 7

I love Linq to SQL, it's very easy to use. Implement the repository pattern and use LINQ to SQL as your first implementation behind your repository interface. You'll find it's so easy to get a repository up quickly using the tool. You can always implement a second repository using NHibernate without breaking your app then compare your experience with the two tools.

NHibernate is "more powerful"... I guess that means you can use it against any database, and that's about it. There's a lot more to learn and if you do go that route, make sure you make full use of Fluent NHibernate to avoid all the mapping rubbish. It's much cleaner that having a bunch of XML mappings to maintain.

I find NHibernate frustrating becuase I like querying the database with LINQ and projecting (mapping) to a model . I know there is a LINQ to NHibernate floating around, but I can't say I know anyone who uses it.

Generally, I would say to use NHibernate if you are happy to get everything by ID and traverse the object model from there. As soon as you want to execute more complex queries you had best be prepared for some frustration.