感觉LinQ更轻量级。
两个都不是什么好东西……
设计思路和发展方向都不一样。
好吃的就是好东西
Ivony兄对它们俩还是如此苦大仇深啊？？呵呵…………：）
LINQ没用过，NHibernate用过一点，当业务逻辑很复杂的时候用起来感觉不方便。
LINQ老实说实现模式有些诡异，复杂的应用很容易大幅提高SQL的复杂程度，而现在LINQ的内置SQL脚本生成逻辑基本上还是靠猜测和实验，如果每写一句复杂的LINQ，都要猜测核试验生成的SQL脚本，那LINQ的意义就大打折扣了。
我觉得还是尽量不要用不熟悉的东西~
不好，LINQ目前还不支持ACCESS，我的项目目前至少要支持ACCESS和SQLSERVER两种数据库
DLINQ只是LINQ中的一部分， 如果仅仅限于对数据库的操作，那么LINQ也就没有太多必要出现了。个人感觉LINQ的出现有利于推动面向对象的开发.
呵呵……LS说的不无道理。
LINQ的出现会催生多样数据储存，我看好XLINQ……，DLINQ说实话现在看起来并不是很好用。
orm实际应用中要考虑性能的话和ado有一定差距的
直接写SQL也没什么不好。
让那些开发.net系统核心的人去研究java，你应该研究.net。
虽然我没有去使用access，但是我相信在互联网上搜索“linq to access”得到的结果要比搜索“linq to db4o”要多多了。
nhibernate 很方便，对象之间的关联，延迟加载，都很方便。节省大量的时间。spring.net有封装了大量的操作和事务，十分方便。
从设计架构、目标，以及现在（vs2008甚至还没有正式发布）已经达到的实际应用，在.Net领域中LINQ思想不是NHibernate思想可比的。
我也是原来一直在用nhibernate。后来看到了dlinq后。生成ORM太方便了。原来要用codesmith生成实体。修改起来很麻烦。
当然是跟着微软走~
当然是LINQ.
生成的SQL效率问题大可以放心,如不放心,可以查看生成的SQL语句.
以前一个网站,用三层写代码,写了一个月,
将数据访问改成LINQ,只写了三天.
感觉非常之爽.
呵呵，不管用什么！你要首先考虑你的用户和你的开发人员。
ok，就说，你都考虑完了，还要考虑你的开发周期。
本人很喜欢ORM的思想，但是，基于在项目中的应用，有些话不得不说。
1.MVC 模式 Model View Controllor 在Web中很美。但是在Winform 中，你不得不考虑你的易用性了！ 也就是当使用Grid时，Grid中的Model 是不是非要点击某个按钮才能新增Model。。。。。
2. View 客户可不管你用的是对象为导向的数据模式，他们只想看到自己需要的数据。那么，开发人员不得不编制很多ViewModel 放置在项目中。这样改动的代价太大；
当然，我个人是十分喜欢ORM，只是指出使用Orm当中，你需要预先考虑的问题。
用LINQ
两个都用，LINQ to NHibernate
从设计架构、目标，以及现在（vs2008甚至还没有正式发布）已经达到的实际应用，在.Net领域中LINQ思想不是NHibernate思想可比的。
==========================
NHibernate和LINQ关注的目标还是不一样的，不过是有些许重叠。
如果是做ASP.NET应用，LINQ还凑合，如果是桌面应用，使用LINQ肯定很失败。为什么？那个.NET 3.5的框架那么大，有几个用户愿意安装？有几个程序员敢作出几百兆的安装包拿出去卖？
LINQ还没用过
还在Spring.NET中．．
要掉队了
LINQ 是战略性的，必将推动开发效率和开发模式的变革
NHIbernate之所以成熟，是因为有hibernate在j2ee开发中多年的印证和积累了.
作项目，用nhibernate， 自己学习还是关注linq 吧，错不了的
没用过linq,不做评论...
刚学习linq，感觉NHibernate好一些，毕竟linq是新生的，还有许多不足的地方。
优劣并存
互补应用
不了
Linq的思路还是对的，对关系型数据与对象设计与开发体系及对业务表达的协调都给出了更加实际的解决方案。
相信Linq以后会向更直接，更方便的方向发展。
要关注一下即将发布beta版的silverlight2.0的信息。4~5M的类库中，包括了wpf所有功能，以及网络服务客户端，以及Linq等等，除了已经支持的windows桌面、mobile、mac os平台以外，即将可以运行在 symbian、linux平台上。
Linq说明 ORM 根本不必那么“繁琐”、“重味道(反正不清香)”。使用一个框架，可以从更大的目标环境出发，而不是从技术出发，繁琐不是好事。
支持LINQ，半年前我也在Nhibernate，后来改用MonoRials,看到LINQ TO SQL以后感觉他的ORM更快速，简单，易上手，毫不犹豫的把整个平台从2。0转移到3。5了。如果楼主项目是2。0话。只能NH咯~。学习的话建议LINQ。NH和MONO的团队还在看微软呢
的确是LINQ看起来更加的易用，对于开发更容易上手。毕竟还有商业化的支持。
DLINQ的执行效率是个问题
大的应用用DLINQ是不现实的,现在我们做开发,DBA是要检验SQL做优化的,那些优化不是DLINQ能提供的,一个检索都是比较复杂的SQL,用DLINQ的话,首先过不了DBA这一关
做中小企业开发差不多
MS这个定位还是和0代码一样,是quick and dirty 开发时用的
用nettiers
事实上现在在JAVA开发里面,也不再倾向于使用HIBENATE这种完全自动化生成SQL的工具了,而是推荐象IBATIS这种可以控制SQL的轻量级ORM工具
LINQ和HIBENATE都是自动化生成SQL,会造成性能瓶颈的,只适合小项目用
看MS准备怎么发展LINQ了
对于dba来说，低层次地调调数据库参数已经不能混下去了。何况数据库越来越不需要手工调整参数，也不是只有dba懂数据库，许多程序员都慢慢懂安装和配置数据库了。
对于IBATIS之类的，都只是进化。而LINQ怎么会比HIBENATE还烂？
偏执于软件组织里的任一个角色，都可以把技术拆得七零八落，每一个角色似乎都是不可或缺的。应用linq主要是对项目整体的提高，有的人喜欢专门配置数据库（而不开发应用软件），有的人喜欢c而不喜欢c#，这是没有办法的事。只是普遍意义上对大多数人来说，linq更能适合程序员提高。
例如界面和数据查询的自动化绑定，你是否总是采用异步读取数据的方式？架构上花点心血斤西瓜改革，这比死抠底层并且抵制架构改变要更有效果。那些新工具最初“总是有一点点运行时期的代价”的，换来的是整体性性能飞跃，例如你把工具升级到新版本或者简单调整一下，程序处处可以提高性能，而不会因为处处都是土法炼钢而升级困难。
当你对Linq不满意的时候，最明智的办法是自己继承它或者监听它的事件，改造它。因为在.net框架内目前还没有可以替代它的更强大的工具！而简单地不去用它，其实是不明智的。
问的好，学习
學習
sp1234狠有见地
是谁应该去关心数据库的性能？能关心到什么程度？
是不是讲会写一些自己认为优化过的SQL，会配一些DB参数，就是DBA了？
术业有专攻，如果程序员都能很好地管理DB了，为什么会存在DBA？DBA每天的工作是什么？
如果一个系统同时在线就那么几百人，那么要DBA是在浪费钱，讨论用hibernate还是ibatis是在浪费时间，你直接拖个0代码的控件上去CRUD就可以了
之所以讨论到高端开发，讨论到有DBA专门去维护管理的系统，就是千万数据量，每秒并发百次的系统
这种系统对性能极其敏感，敏感到每一句SQL都必须优化，不能容忍任何对性能的浪费，DBA会每隔1小时获取一次DB的分析日志，得到浪费资源最大的SQL，分析出系统的瓶颈
如果一个系统在开发时不能获取到所有SQL评审，那么有些设计可能就很难改了，花费的时间是海量的！
我现在就碰到因为一个字段，动用几十名DBA，无数开发人员一年的时间去修改！
这种情况下你用LINQ???
讨论的就是高端开发的情况，所以，不要以中小系统为目标，如果LINQ只是又一个quick and dirty的RAD工具，那么它还是进不了企业级开发的市场的
ls发言精妙极了!
每秒并发百次的关系数据库哪些能做到？
我做过每月新增几十个G数据量的上千万用户数的项目，数据库优化没有你说的那么厉害。
每天几十万访问量，“DBA会每隔1小时获取一次DB的分析日志”这只有在小数据库量的理论上才能做到，实际上只有在系统几乎跨了的时候（有重大bug就仓促上线造成问题的时候），才“敢”去开启数据库日志，不得已才去实时采集性能日志。你知道大型数据库的日志如果开启，要降低多少处理时间吗？
每天几十万访问量 => 每天几百万访问量
真实的生产系统，能够达到几百万到顶？可以算算。
可能你作为一个程序员参与了一个大型项目，但是对性能问题不是参与者可以说清楚的，必须是负责任过才知道。
大型项目不使用新技术，那是有历史原因的。
对于数据库的字段如何设计，跟linq没有关系。linq是使用数据库，而不是设计数据库。
嗯，我又发现一个断言不太正确：
这只有在小数据库量的理论上才能做到 => 这只有在貌似大数据量但是很小访问量时理论上才能做到
up,继续看你们讨论
很可惜，我是作PM来做这个项目的
CSDN的等级可不是人的能力等级
事实上TAOBAO就是这么干的
TAOBAO的并发是超过百次的,数据库可远比你想象的强大,看你会不会配了
专职DBA的工作就是干这个
还是想使用一个比较好一点的架构 要不MVC到底也没有什么意思
“每秒并发百次”不等于“每秒数据库并发百次”，而且“并发”这个词其实缺少关键的一半，并发干什么？并发等待数据库？并发脏读？并发读快照？并发事务？并发在内存中处理？
淘宝之类的网站能得到“强大”的印象，这有点让人不以为然。我还当会举出繁忙的电信业务、高速机车控制项目、每秒新增几万个对象（至少几千个必须存在数据库中）的数据采集任务，这些都已经在使用linq。
不必一谈到数据库就仅仅想到那3、4中关系数据库。何况那3、4种流行的关系数据库也有很多“特殊版本”用来处理高速、面向对象等特殊情况，特殊版本全都有特殊的“原生查询”语法。这也仅仅是“通用”而已，而通用的关系数据库总是最慢的。
且不管“凡是都用通用关系数据库管理那三板斧”是否是软件设计必要的，linq只是语言的扩展，把程序语言直接编译为数据库的原生查询语言（比通用的SQL更深入到数据库引擎内部），这是趋势。
如果淘宝真的如所说“现在就碰到因为一个字段，动用几十名DBA，无数开发人员一年的时间去修改！ ”，那么淘宝真的是个练手者的逍遥乐园。
1.我说的并发百次是指每秒并发百次以上事务。关于并发这一点，我觉得你可以先去查查ORACLE的能力。
2:你说的电信和机床项目我也都做过，不妨讲来听听?
3:数据采集和前置机，如果不优化SQL，不考虑每秒并发，很容易把DB跑垮的，原来见过一个前置机，就经常用存储过程把DB跑垮
面向对象现在在一些东西上还不成熟,现在的通用数据库还都不是面向对象的，要从面向对象的语言向数据库沟通，目前仍然是采用SQL这种结构化的东西，如果项目大起来，程序员数量多起来，那么如何保证SQL的优化？
一两个高手，用熟了LINQ，懂得去跟踪调整SQL还好，但是其他的程序员呢？难道都能这样？如果没有专职DBA去优化SQL，指导程序员，很难想象最终项目的性能，而DBA很多是不懂编程语言的，你要他们去调试LINQ？现在这里的DBA是禁止使用面向对象的ORM工具的，必须能整理出清晰的SQL提供给DBA评审。如果用LINQ绕了一大圈，又跑去跟踪获取SQL又要调整，那这个LINQ也就失去意义了~
如果没有DBA去评审SQL，没有DBA去监视数据库，那就会产生这种因为某几个字段导致的大问题
把DB交给程序员去随心所欲去危险的
为什么要有DBA这种职位？
高手打仗，菜鸟学习。
我觉得还是用NHibernate好。用linq就得承受从2.0迁移到3.5的风险。
mark
这个简单啊,网上搜一下就得到答案了.
接分是王道！
两位高手过招了,学了很多招式
我认为LINQ的语法真的很糟糕,真的不如用SQLHELPER直接调用存储过程来的方便,而且存储过程可以让专人去优化,这多方便啊
奥对了,顺便发布一个网址http://www.ayende.com/Blog/archive/2007/03/16/Linq-for-NHibernate.aspx
就在你们过招的同时,老外们已经吧nhibernate与linq整合了
linq没怎么用我一直都是在用NHibernate的!!
不知道linq效果怎么样!!
mark
端个小凳坐着，慢慢看……
奥对了,顺便发布一个网址http://www.ayende.com/Blog/archive/2007/03/16/Linq-for-NHibernate.aspx
就在你们过招的同时,老外们已经吧nhibernate与linq整合了
