NHibernate或Linq to SQL[关闭]

我问自己一个非常相似的问题,除了我想的是威尔森诺姆,我认为这是一个不错的选择。

在我看来,有许多重要的区别。

LINQ:

• 不是一个完整的ORM工具(您可以使用一些附加的库,比如最新的实体框架——我个人认为,与其他ORM框架相比,MS最新技术的体系结构大约有10年的历史)
• 主要查询支持IntelliSense的“语言”(编译器将检查查询的语法)
• 主要用于Microsoft SQL Server
• 是封闭源

NHibernate:

• 是ORM工具
• 有相当有限的查询语言,没有IntelliSense
• 几乎可以与任何具有数据库提供程序的DBMS一起使用
• 是开源的

这要看情况而定。如果您开发一个富(Windows)桌面应用程序,需要在其中构建对象,使用它们,并最终坚持它们的更改,那么我建议您使用类似nhibernate的ORM框架。

如果您开发的Web应用程序通常只查询数据,并且只偶尔将一些数据写回数据库,那么我建议您使用好的查询语言,如LINQ。

和往常一样,这要看情况而定。-)

埃尔尔…有 LINQ for NHibernate .

也许你的意思是使用哪一个:

• 解决并发冲突
• NHiBiNATE

我更喜欢NHibernate。

LinqToSQL相当轻,但它与数据结构的耦合程度稍高,而nhibernate在可以映射到表结构的对象定义类型方面相当灵活。

当然,这并不是说linq-to-sql没有用处:这个网站使用它。我相信在数据库模式不那么庞大的小应用程序中启动和运行是非常有用的。

从NHibernate开始是个坏主意。只有巧妙的设置才能显示出良好的性能。尝试在大型项目中使用EFv4,在中小型项目中使用L2S(可能是第三部分产品)。这些产品比NHibernate更方便、更灵活,让您可以快速启动。

不是完整的清单

林奇托尔 赞成的意见:

• 更好的工具支持
• 好的LINQ供应商
• 当db schema==类时,很容易开始-

反对的论点:

• 不灵活(即数据库模式!=类)
• 仅支持MS SQL Server
• 无层叠(保存、更新…不级联到引用的对象)

NHiBiNATE 赞成的意见:

• 很多RDBMS支持OOTB
• 特征丰富
• 几乎所有角箱都非常灵活
• 开放源代码

反对的论点:

• 一开始就不那么容易
• 不是来自MS
• 有很多工具,但你必须搜索

在两个窗体之间

如果:

• DB架构==类
• 仅使用过MS SQL Server
• 商店只允许MS产品

如果:

• 更丰富的对象模型
• 旧数据库架构
• 数据库而不是MS SQL Server或支持多个
• 性能关键(我认为NH比LinqToSQL有更多的特性来优化性能)

注:这是我的个人观点。我主要处理(疯狂的)遗留DBS和复杂的ETL作业,其中对象模型对SQL有很大帮助。

我不使用(甚至不知道)nhibernate,我只想给出我的证词:我使用linq-to-sql大约2年,使用my sql和postgresql数据库(使用 DbLinq 在Windows上,使用 Mono 在Linux和Mac OS X上)。

因此,Linq to SQL不仅限于Microsoft产品。

我可以确认LinqToSQL非常适合中小型项目,或者您完全控制数据库结构的大型项目。 正如评论所指出的,当数据库表和实体类之间没有直接映射时,LINQ to SQL有一些限制,使其成为不合适的工具。

注意:Linq to SQL不支持多对多关系(但只需几行代码就可以轻松实现)。

NHibernate的主要缺点是无法利用 方法调用 . 它们无法转换为SQL。为了避免这种情况,你必须重新创建表达式树,这是很难做到的。