When choosing an ORM, is LINQ to SQL or LINQ to En

问题:

I find I can do more with NHibernate, and even Castle than with the Linq to Entities, or linq to SQL.

Am I crazy?

回答1:

No you're not crazy. nHibernate is a full OR Mapper, Linq to SQL and Linq to Entities don't implement everything you'd expect from an OR mapper and targeted at a slightly different group of developers.

But don't let that put you off linq though. Linq is still a pretty good idea.. Try Linq to nHibernate :-)

回答2:

The big drawbacks to NHibernate, Castle, etc., is that they're not exactly light-weight (especially NHibernate.)

Linq to SQL is good for a light-weight, limited use ORM.

回答3:

I've used both NHibernate and LINQ to SQL. From my point of view it depends on the project, if I need something quick, I would choose L2S, it's so simple to create the dbml mapping and start using it. If I'm developing a more highlevel enterprise solution I would go for the tried and trusted ORM - NHibernate, I find the logging & transaction features simple to use.

LINQ to SQL has a relatively short learning curve, NHibernate has a much steeper learning curve.

LINQ to SQL only supports SQL Server, so if you've an Oracle database then the decision is already made - NHibernate.

I'd recommend checking out http://www.summerofnhibernate.com/ for excellent screencasts on learning NHibernate.

回答4:

One thing to bear in mind is that NHibernate can be an absolute pig to configure - especially since its based mainly on XML config files because of its roots as the original Hibernate.

Fluent NHibernate goes some way to making this less painful.

Linq certainly though fits in with the general 'way' in which .NET works.

回答5:

Blockquote Linq certainly though fits in with the general 'way' in which .NET works

Yikes, this kind of sentiment scares me. The RAD stuff built into .net is NOT how dot net works, it's just a tool set for getting prototypes up. .NET allows us to do full DDD applications, w/ high levels of cohesion, seperations of concerns, and allows us to write decoupled code, despite all the attemps ms makes to couple things. I would strongly disagree that .net likes to be coupled, certian tools like to be coupled, i'll include linq to sql in this fray. linq to sql destroys the idea of having a seperate domain model. I cringe at the thought of using my database schema as the underlying model objects. Proper ORM tools should allow us to model our domain first, then link our relational database to these models. NOT the other way around.

回答6:

I have not tried the Entity Framework, but I definitely would recommend NHibernate over Linq to SQL; The biggest reason I can give is just the control. Linq to SQL likes to have a lot more control over everything, loading the object and maintaining all kinds of tracking information about the object. If you serialize/deserialize, the tracking information can be lost and strange things can happen when saving it again. NHibernate works more as a repository should - You hand it whatever object you want (that you have configured it to understand, of course), and it puts it away in the database, regardless of what you've done with it.