LINQ to SQL vs. NHibernate

To be honest, I have to say that my next project will use NHibernate for its persistence technology instead of LINQ to SQL. Why? It is a large project, with a significant number of entities, and we want to support fine-grained object models and table per sub-class mapping strategies. We also wanted the insurance of being able eager fetch on a query-by-query basis and have a 2nd level cache. It is an old adage but 'there is no silver bullet'. I'm picking one tool out of the kit, it does not mean the others are not valuable.

At the same time LINQ to SQL still forms part of our strategy, because we believe it to be simpler to approach for many projects.So we also have and will be using LINQ to SQL. If anything LINQ to SQL replaces WORM for us which we used for a number of projects where we had good table to entity affinity. Ironically perhaps WORM was an implementation of the proposed interface for ObjectSpaces. ObjectSpaces was the MS ORM for .NET 2.0, that never saw the light of day. ObjectSpaces became LINQ to SQL, and Matt has full the story here, so it seems a natural inheritor. Let us hope it does not meet the ObjectSpaces fate of being sidelined for a more grandiose vision of data access.

A valid question might be to ask why I want improve LINQ to SQL, why I do not just tell everyone to use NHibernate. Some of this is a recognition of the market, many people will not use a non-MS ORM and LINQ to SQL is is a solid ORM. Pragmatically we are likely to get more .NET developers who know LINQ to SQL available in the market place than NHibernate developers. But I also believe that with the expressiveness of LINQ MS have a real chance to move the ORM market forward in the .NET space. LINQ to SQL is like ASP.NET MVC, it is a welcome acknowledgement from MS of what developers want, and we should commend them when they do get it right.

I will be posting a series on NHibernate going forward, so that you can make your own judgements on which to use and when.

from http://codebetter.com/blogs/ian_cooper/archive/2008/07/01/architecting-linq-to-sql-part-10.aspx

转载于:https://www.cnblogs.com/baixingfa/archive/2008/08/07/1263234.html

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
Entity Developer是一个强大的ORM设计器,支持 ADO.NET Entity Framework, NHibernate, LinqConnect 和 LINQ to SQL。你可以使用模型首先和数据首先的方法设计ORM模型并生成C#或者Visual Basic .NET代码。它引入了新的方法设计ORM模型,提高开发效率,简化数据库应用的开发。 可视化ORM模型设计器并支持代码生成 Entity Developer允许你可视化创建和编辑NHibernate,Entity Framework,LinqConnect 和 LINQ to SQL模型,无需一行XML代码。它支持创建各种一映射,如表分割,映射实体到多个表,复杂类型,继承分层,从Sel ect语句创建实体,从SQL代码创建方法等。由于使用了类似T4的模板,所以代码生成非常灵活,另外你还能创建自己的模板用于其他的编程语言。 多ORM支持 Entity Developer 支持 NHibernate, Entity Framework,LinqConnect 和 LINQ to SQL模型。 强大的代码生成 Entity Developer提供基于T4类似的模板生成代码框架,针对不同使用情况提供大量预定义的模板,模板化生成上下文,实体,映射,支持流,属性和XML映射,包括持久层感知和持久层无感知实体,支持验证框架等。另外模板提供自动生成MVC Controller和视图的功能。Data Transfer Object 提供转换器类和Data Annotations metadata类。 适用于各种.NET ORM的可视设计器 Entity Developer可以帮助您在一个统一的界面中为各种.NET ORM设计模型。您可以在一个工具中获得对所有ORM的支持,或者您可以购买单独的版本,与其中一个受支持的ORM一起使用。 支持EntityFramework和EF Core 对于Entity Framework v1-v6以及最新的EF Core2.2,我们的设计器提供了比EDM设计器更多的设计和代码生成功能。 Entity框架核心 设计实体框架核心模型可视化。通过大量设置获得模型优先和数据库优先支持。 NHibernate 直观地编辑NHibernate模型,为NHibernate 3或4生成XML,流畅或Loquacious映射和配置。 LINQ to SQL 直观地设计LINQ to SQL模型。 获得更好的模型优先和数据库优先支持,并轻松将模型更改应用于数据库。 LinqConnect 积极支持Devart的LINQ to SQL兼容ORM以及更多功能,Entity Developer作为其ORM设计器。 Telerik数据访问 可视化设计最新Telerik数据访问版本的模型,并通过Fluent Mapping API生成仅代码映射。 功能丰富的设计器,具有强大的代码生成功能 无缝Visual Studio集成 支持Model-First和Database-First 可视化创建几乎所有类型的映射 将模型更改应用于数据库,反之亦然 强大的模型重构 优化大型模型的工作 设计时LINQ / ESQL / HQL查询执行 查看和编辑源表中的数据 背景模型验证 基于T4模板的代码生成 大量预定义模板 生成C#或VB代码 每个类的文件,部分类生成 自定义属性支持 自定义模板支持 带语法高亮的模板编辑器 高质量的生成代码 高度可定制的一代

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值