YALONQ....

kev160967 · **Posted:** Wed Jan 30, 2008 6:52 am

Or Yet Another Linq Or NHibernate Question...

Hi,
I've been using NHibernate for the last few months, and have been pushing to adopt it as our standard for new development. One of my colleagues is keen to just go with Linq for SQL instead. We've got a meeting next week where we are going to decide what is the best option. My problem is that whilst I'm happy with what NHibernate gives me, I'm not that familiar with the LINQ alternative. I've just had a little play with generating a model using it for a project I've previously done with NHibernate, and it does seem to cover quite a lot of ground. So far I'm not sure what to say in NHibernate's favour other than it is a far more mature product, which we have proven to work on several exising projects. I'd really like to be able to come out with some more concrete points though.

By the way, I'm aware of the NHibernate Linq add on, but my colleague's response will inevitably be that that's all very well, but why bring NHibernate into the picture when we can just use Linq without it.

Kev

rogermoore · **Joined:** Tue Mar 27, 2007 4:54 am **Posts:** 47

One major, major drawback with linq to sql is that there's no support for value objects (nhib's "component"). And, as far as I know, there's really no good work around. At least to me, it's a very important feaure.

jchapman · **Joined:** Thu Feb 09, 2006 1:30 pm **Posts:** 172

Most advanced features (and even simple ones like many-to-many mappings) of NHibernate are missing in Linq to Sql. For more detail, I wrote a blog entry about this a while back. Read it here: http://jaychapman.blogspot.com/2007/12/linq-to-sql-good-bad-bottom-line.html.

Woil · **Posted:** Wed Jan 30, 2008 1:51 pm

Here's an article by Rob Conery who wrote some of the new MVC framework on the different mapping options out there:

http://blog.wekeroad.com/2007/12/14/aspnet-mvc-choosing-your-data-access-method/

From the article:

Quote:

NHibernate is a port of the Hibernate Core project from Java. Given it’s history and maturity level, there is a certain amount of "weight" involved with it that you’ll need to get used to. This isn’t a negative statement at all - it’s just been around for a while and has a lot of features to it.

Getting started with NHibernate can be a bit intimidating at first, but once you ramp up you will no doubt have twice the feature set of SubSonic and LinqToSql. Features mean learning and reading - and if you like diving into an API, this is a good choice.

NHibernate also has a very large following, and members of the core team are prolific bloggers who discuss how to do things with the toolset quite often.

There’s not much you can’t do with NHibernate, and all in all it’s probably the most comprehensive ORM tool around.

kev160967 · **Posted:** Thu Jan 31, 2008 6:00 am

Thanks for the responses. Kind of makes a bit more concrete what I've been thinking.

Unfortunately, unless I can resolve the problem (http://forum.hibernate.org/viewtopic.php?t=983340) with porting the legacy system I'm about to start work on, we might be forced to go with linq to sql after all. At the moment it looks like NHibernate may not be able to handle the keys. Since this is likely to be the main project we are working on for the next 6 months anything we go with is likely to become the de facto standard :-(

jchapman · **Joined:** Thu Feb 09, 2006 1:30 pm **Posts:** 172

Have you actually tried the scenario you are describing with Linq to Sql? I highly doubt this would be supported there either.

kev160967 · **Posted:** Fri Feb 01, 2008 5:50 am

jchapman wrote:

Have you actually tried the scenario you are describing with Linq to Sql? I highly doubt this would be supported there either.

I did a small test project yesterday, and unfortunately it appears to work without problem! Here's the schema and code:

schema

Code:

CREATE TABLE Parent(
   Prefix char(2) NOT NULL,
   ID int IDENTITY(1,1) NOT NULL,
   Name varchar(50) NOT NULL,
 CONSTRAINT PK_Parent PRIMARY KEY CLUSTERED (Prefix ASC, ID ASC)
) 

CREATE TABLE Child(
   Prefix char(2) NOT NULL,
   ID int IDENTITY(1,1) NOT NULL,
   ParentPrefix char(2) NOT NULL,
   ParentID int NOT NULL,
   Name varchar(50) NOT NULL,
 CONSTRAINT PK_Child PRIMARY KEY CLUSTERED (Prefix ASC, ID ASC)
)

ALTER TABLE Child  WITH CHECK ADD  CONSTRAINT FK_Child_Parent FOREIGN KEY(ParentPrefix, ParentID)
REFERENCES Parent (Prefix, ID)

And here's the code:

Code:

Dim db As DBDataContext = New DBDataContext
Dim parent = New Parent
parent.Prefix = "SF"
parent.Name = "Father"
db.Parents.InsertOnSubmit(parent)
Dim child = New Child
child.Prefix = "SF"
child.Name = "Son"
parent.Childs.Add(child)
child = New Child
child.Prefix = "SF"
child.Name = "Daughter"
parent.Childs.Add(child)
db.SubmitChanges()
Dim children = From test In db.Childs Where test.Parent Is parent Select test
For Each ctest As Child In children
  Debug.WriteLine(String.Format("{0}{1} {2} <= {3}{4} {5}", ctest.Prefix, ctest.ID, ctest.Name, ctest.Parent.Prefix, ctest.Parent.ID, ctest.Parent.Name))
Next

This produces the following output, as expected:

Quote:

SF9 Son <= SF6 Father
SF10 Daughter <= SF6 Father

So, it looks like NHibernate is lagging a bit behind on this one :-(