Replacing NHibernate with LINQ to SQL or LINQ to EF_问答_开发者

We have a great project t开发者_如何学JAVAhat use NHibernate as ORM. We want to migrate to L2S or L2EF. Can we do everything that we do by NHibernate?

Do you propose us that doing this work? What is the advantages and disadvantages of this work? Are these two ORMs have common capabilities?

Note: Our project written in C#.

Do you have a compelling reason to change your ORM? I would argue to not change anything since you have an existing application that works well using a good persistence framework that is well supported.

Yes, you will be able do anything you are doing currently with NHibernate with the entity framework (not so sure about LINQ to SQL though) but don't switch for the sake of the framework. That would be like switching out the tires on your car a week after you bought them - it may be exciting to have new shiny tires but at the end of the day, they're just tires. The tires you have now are just fine - perhaps there are other areas of the application that would better benefit from the time that you have allotted for this project?

Unless you have a really good reason to change your ORM, this will be vastly more pain than it's worth. Changing ORM is as significant a change as swapping your database provider.

There will be features in NHibernate that are not present in other ORM tools (components spring to mind immediately), so you would have to find work-around or redesign classes or table structures to compensate for the changes.

Should you do this work? I'd recommend not.

If you're going to switch I would strongly advise against using linq to sql as the future is very unclear. As far as feature differences between NHibernate and linq to entities Ayende Rahien has some blog posts regarding differences.

nhibernate vs. entity framework 4.0
responding to how ef is better
what can ef 4.0 do that nhibernate can't

FYI: Ayende is a contributing member of the NHibernate team.

In regards to your second question. It would be hard to propose doing this work with out knowing how NHibrinate is failing you. Depending on the state and size of the product I would be very hard pressed to recommend a changing an integral piece of a application like an ORM with out very well thought out reasons.

In any case, NHibrinate is a very solid product and has a long track record in the .net open source community. Microsoft on the other hand has a history of introducing Data Access / ORM solutions and abandoning them quickly.

Linq to SQL does not support anywhere near the entire feature set of NHibernate. I use Linq to SQL and think it's great, but it's intended to be used as a direct 1:1 mapping against the database. It's a bit less of a true ORM than NHibernate and more of a data access solution. Among other things, it's missing:

Component properties;
Many-to-many mappings;
Automapping (although the designer tools mostly make up for it);
Multi-platform support (Linq to SQL only really supports SQL Server and SQL CE)
Mapping multiple tables into a single class

Entity Framework 4 is very close to NHibernate in terms of its feature set and you should be able to do most of what you're currently able to do in NHibernate. But I whole-heartedly agree with the others advising against changing your ORM just for fun; the actual semantics are very different and you will end up going through a lot of pain and bugfix cycles.

What is your reason for wanting to migrate? Does the existing solution not work? Is it a performance issue? I would recommend taking a little time making sure that you understand what the issues are, performance or otherwise, and focus on these. With the right indexes on your database and using NHibernate fetures such as batching, you might find that your issues are solved without a rewrite.

Also, look at LinqToNHibernate as a first step. The Linq syntax will be the same as what you would end up using anyway. That is the beauty of Linq.

NHibernate allows you to implement your logic without calling the DAL all the time ("persistence ignorance"). This is possible because NH compare the instances in memory and automatically detects changes.

It has great performance features (eg. the cache, query batching, insert/update batches, lazy loading).

When using NHibernate the right way, you write your application as if there wasn't any persistency (lets say: to 80%) and still get high performance. Since Linq to Sql or EF do not provide this ability (AFAIK), I can't imagine how you can migrate a large application to that. Your code will need to call the DAL all the time, where currently it doesn't.