blocks|key|1594099|text|你有一个令人信服的理由来改变你的ORM吗？我主张不做任何更改，因为您有一个现有的应用程序，该应用程序使用一个良好的持久化框架工作得很好，并且得到了良好的支持。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1594100|是的，你可以使用entity框架来做任何你目前正在用NHibernate做的事情(虽然对LINQ+to+SQL不是很确定)，但是不要为了框架而切换。这就像在你买车一周后换掉轮胎一样--有了新的闪亮的轮胎可能很令人兴奋，但归根结底，它们只是轮胎。您现在拥有的轮胎很好-也许应用程序的其他方面会从您分配给这个项目的时间中获得更好的好处？|1594101|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

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?

blocks|key|315822|text|您想要迁移的原因是什么？现有的解决方案不起作用吗？这是一个性能问题吗？我建议花一点时间确保您了解问题是什么，性能或其他方面，并专注于这些问题。通过在数据库上建立正确的索引并使用批处理等NHibernate+fetures，您可能会发现无需重写即可解决问题。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|315823|另外，将LinqToNHibernate作为第一步。Linq语法将与您最终使用的语法相同。这就是Linq的美妙之处。|315824|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

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.

blocks|key|1594178|text|除非你有一个很好的理由去改变你的ORM，否则这将是更多的痛苦而不是它的价值。更改ORM与交换数据库提供商一样重要。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1594179|NHibernate中将会有其他对象关系管理工具中没有的特性(组件会立即浮现在脑海中)，因此您必须找到解决办法，或者重新设计类或表结构来弥补这些变化。|1594180|你应该做这项工作吗？我建议你不要这么做。|1594181|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

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.

blocks|key|3003028|text|NHibernate允许您实现您的逻辑，而无需一直调用DAL+(“持久性忽略”)。这是可能的，因为NH比较内存中的实例并自动检测更改。|type|unstyled|depth|inlineStyleRanges|offset|length|style|BOLD|entityRanges|data|3003029|它具有出色的性能特性(例如，缓存、查询批处理、插入/更新批处理、延迟加载)。|3003030|当以正确的方式使用NHibernate时，您编写的应用程序就好像没有任何持久性(比方说:+80%25)，并且仍然可以获得高性能。由于Linq+to+Sql或EF不提供此功能(AFAIK)，我无法想象如何将大型应用程序迁移到AFAIK。您的代码将需要一直调用DAL，而目前它不需要。|3003031|entityMap^0|X|5|0|6|2|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@$9|M|A|N|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|O|8|@$9|P|A|Q|B|C]]|D|@]|E|$]]|$1|H|3|I|5|6|7|R|8|@]|D|@]|E|$]]|$1|J|3|-4|5|6|7|S|8|@]|D|@]|E|$]]]|K|$]]

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.

blocks|key|1064772|text|如果您打算改用linq+to+sql，我强烈建议您不要使用linq+to+sql，因为未来是very+unclear。至于NHibernate和linq+to+entities之间的功能差异，Ayende+Rahien有一些关于差异的博客文章。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|1064773|1064774|nhibernate+vs.+entity+framework+4.0|ordered-list-item|1064775|responding+to+how+ef+is+better|1064776|what+can+ef+4.0+do+that+nhibernate+can't|1064777|1064778|仅供参考:阿延德是NHibernate团队的一名贡献成员。|1064779|关于你的第二个问题。在不知道NHibrinate是如何让你失望的情况下，很难提议做这项工作。根据产品的状态和大小，我很难建议在没有经过深思熟虑的原因的情况下更改应用程序的一个组成部分，比如ORM。|1064780|在任何情况下，NHibrinate都是一个非常可靠的产品，并且在.net开源社区中有着长期的记录。另一方面，微软有引入数据访问/+ORM解决方案并迅速放弃它们的历史。|1064781|entityMap|0|LINK|mutability|MUTABLE|url|http://blogs.msdn.com/adonet/archive/2008/10/29/update-on-linq-to-sql-and-linq-to-entities-roadmap.aspx|1|http://ayende.com/Blog/archive/2010/01/05/nhibernate-vs.-entity-framework-4.0.aspx|2|http://ayende.com/Blog/archive/2009/12/25/responding-to-how-ef-is-better-nh-commentaryhellip.aspx|3|http://ayende.com/Blog/archive/2009/12/24/what-can-ef-4.0-do-that-nhibernate-canrsquot.aspx^0|1A|C|0|0|0|0|Z|1|0|0|U|2|0|0|14|3|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|16|8|@]|9|@$A|17|B|18|1|19]]|C|$]]|$1|D|3|-4|5|6|7|1A|8|@]|9|@]|C|$]]|$1|E|3|F|5|G|7|1B|8|@]|9|@$A|1C|B|1D|1|1E]]|C|$]]|$1|H|3|I|5|G|7|1F|8|@]|9|@$A|1G|B|1H|1|1I]]|C|$]]|$1|J|3|K|5|G|7|1J|8|@]|9|@$A|1K|B|1L|1|1M]]|C|$]]|$1|L|3|-4|5|6|7|1N|8|@]|9|@]|C|$]]|$1|M|3|N|5|6|7|1O|8|@]|9|@]|C|$]]|$1|O|3|P|5|6|7|1P|8|@]|9|@]|C|$]]|$1|Q|3|R|5|6|7|1Q|8|@]|9|@]|C|$]]|$1|S|3|-4|5|6|7|1R|8|@]|9|@]|C|$]]]|T|$U|$5|V|W|X|C|$Y|Z]]|10|$5|V|W|X|C|$Y|11]]|12|$5|V|W|X|C|$Y|13]]|14|$5|V|W|X|C|$Y|15]]]]

If you're going to switch I would strongly advise against using linq to sql as the future is <a href="http://blogs.msdn.com/adonet/archive/2008/10/29/update-on-linq-to-sql-and-linq-to-entities-roadmap.aspx" rel="nofollow noreferrer">very unclear</a>. As far as feature differences between NHibernate and linq to entities Ayende Rahien has some blog posts regarding differences. 

<ol>
<li><a href="http://ayende.com/Blog/archive/2010/01/05/nhibernate-vs.-entity-framework-4.0.aspx" rel="nofollow noreferrer">nhibernate vs. entity framework 4.0</a></li>
<li><a href="http://ayende.com/Blog/archive/2009/12/25/responding-to-how-ef-is-better-nh-commentaryhellip.aspx" rel="nofollow noreferrer">responding to how ef is better</a></li>
<li><a href="http://ayende.com/Blog/archive/2009/12/24/what-can-ef-4.0-do-that-nhibernate-canrsquot.aspx" rel="nofollow noreferrer">what can ef 4.0 do that nhibernate can't</a></li>
</ol>

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.

blocks|key|1061248|text|Linq+to+SQL不支持任何接近NHibernate的整个特性集的。我使用Linq+to+SQL，我认为它很棒，但它的目的是用作数据库的直接1:1映射。与NHibernate相比，它不是真正的对象关系映射，而更像是一种数据访问解决方案。在其他东西中，它缺失了：|type|unstyled|depth|inlineStyleRanges|offset|length|style|BOLD|entityRanges|data|1061249|SQL+Server组件properties;|1061250|Many-to-many+mappings;|unordered-list-item|1061251|
|1061252|Automapping+(尽管设计器工具主要弥补了对it);|1061253|1061254|Multi-platform的支持(Linq+to+SQL实际上只支持|1061255|和SQL+CE)|1061256|将多个表映射到单个类|1061257|1061258|1061259|Entity+Framework4在其特性集方面与NHibernate非常接近，您应该能够在NHibernate中完成当前所能做的大部分工作。但我完全同意其他人的建议，不要仅仅为了好玩而改变你的ORM；实际的语义是非常不同的，你最终会经历很多痛苦和错误修复周期。|1061260|entityMap^0|Z|2P|0|0|N|0|0|M|0|0|0|U|0|0|0|Z|0|0|8|0|0|A|0|0|0|0|3N|0^^$0|@$1|2|3|4|5|6|7|11|8|@$9|12|A|13|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|14|8|@$9|15|A|16|B|C]]|D|@]|E|$]]|$1|H|3|I|5|J|7|17|8|@$9|18|A|19|B|C]]|D|@]|E|$]]|$1|K|3|L|5|6|7|1A|8|@]|D|@]|E|$]]|$1|M|3|N|5|J|7|1B|8|@$9|1C|A|1D|B|C]]|D|@]|E|$]]|$1|O|3|L|5|6|7|1E|8|@]|D|@]|E|$]]|$1|P|3|Q|5|J|7|1F|8|@$9|1G|A|1H|B|C]]|D|@]|E|$]]|$1|R|3|S|5|J|7|1I|8|@$9|1J|A|1K|B|C]]|D|@]|E|$]]|$1|T|3|U|5|J|7|1L|8|@$9|1M|A|1N|B|C]]|D|@]|E|$]]|$1|V|3|-4|5|6|7|1O|8|@]|D|@]|E|$]]|$1|W|3|-4|5|6|7|1P|8|@]|D|@]|E|$]]|$1|X|3|Y|5|6|7|1Q|8|@$9|1R|A|1S|B|C]]|D|@]|E|$]]|$1|Z|3|-4|5|6|7|1T|8|@]|D|@]|E|$]]]|10|$]]

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:

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

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.

We have a great project that 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#.

Replacing NHibernate with LINQ to SQL or LINQ to EF

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

我们有一个很棒的项目，它使用NHibernate作为对象/对象模型。我们希望迁移到L2S或L2EF。我们可以像NHibernate那样做所有的事情吗？你建议我们做这项工作吗？这项工作的优点和缺点是什么？这两个ORM有共同的功能吗？注意:我们的项目是用C#编写的。

问用LINQ to SQL或LINQ to EF替换NHibernate
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问用LINQ to SQL或LINQ to EF替换NHibernateEN