当前在线人数16059
[合集] some1 using nhibernate? - 未名空间精华区
首页 - 版面精华区 - 电脑网络精华区 - 窗口里的风景版精华区 - 精华区文章阅读 首页
未名交友
[更多]
[更多]
[合集] some1 using nhibernate?

发信人: cogt (苦荆茶), 信区: DotNet
标  题: [合集] some1 using nhibernate?
发信站: BBS 未名空间站 (Sat Dec  1 22:12:01 2007), 站内

☆─────────────────────────────────────☆
  flyfire (flyfire) 于 (Wed Nov 14 01:03:05 2007) 提到:

anyone has experience with that?


☆─────────────────────────────────────☆
  depend (depend) 于 (Wed Nov 14 07:52:58 2007) 提到:

正在尝试中,想从Nhibernate和Linq to Sql / Entity Framework 里选一个


☆─────────────────────────────────────☆
  les (Walk the walk, talk the talk) 于 (Wed Nov 14 13:33:15 2007) 提到:

写个总结给你发个大包子.:)


☆─────────────────────────────────────☆
  flyfire (flyfire) 于 (Wed Nov 14 22:06:16 2007) 提到:

问个问题呀。
If i don't know the table structure at design time, how could I use
nhibernate in such situation. Could I get a generic object from nhibernate?
Just like use ado.net to get a generic dataset (not strong typed)



☆─────────────────────────────────────☆
  depend (depend) 于 (Wed Nov 14 22:14:15 2007) 提到:

在ORM里,business object是和数据库分开的,二者用一个映射文件连接,

因此,你可以把现有的business object和数据表对应起来,以后修改表结构的时候,

只需要修改那个映射文件就可以了,基于business object的代码不需要变动。

当然,经常遇到的情况是修改表结构的时候发现business object的定义也要改,

这个时候就business代码也就需要修改了。

你说的not strong typed是什么意思?让Nhibernate返回一个object然后再cast?



☆─────────────────────────────────────☆
  depend (depend) 于 (Wed Nov 14 22:20:25 2007) 提到:

目前ORM还没有正式在我们系统中使用,目前只在调研阶段,

我有时间的话可以纸上谈兵一下。



☆─────────────────────────────────────☆
  flyfire (flyfire) 于 (Wed Nov 14 23:04:12 2007) 提到:

what's the difference between ORM and strong-typed dataset?

: 你说的not strong typed是什么意思?让Nhibernate返回一个object然后再cast?
Yes. I have some data tables created at run time. I am wondering if
nhibernate can handle such situation. If not, I am going to stick to ado.net
I think LINQ can handle this.


☆─────────────────────────────────────☆
  NeverLearn (Working Procedure) 于 (Thu Nov 15 02:38:56 2007) 提到:

Why use nhibernate while LINQ and Entity Framework are coming out?
M$ default product can only be better.



☆─────────────────────────────────────☆
  alexx (panda in love~八胖~饲羊员~水木十年) 于 (Thu Nov 15 07:19:54 2007) 提到:

呼唤好虫~~~


☆─────────────────────────────────────☆
  depend (depend) 于 (Thu Nov 15 18:37:22 2007) 提到:

我不太喜欢Linq To Sql,自带的工具可调参数太少,用户很难把它集成到现有系统中
去,

我问过微软的人,他们也同意这些问题,但是在第一个release里不会有太大的改进。

EF没怎么用过,不予评论。

喜欢NHibernate是因为它是open source,不满意的地方可以自己改。

你的第二句话是认真的还是开玩笑?



☆─────────────────────────────────────☆
  cute (小可爱) 于 (Thu Nov 15 20:10:10 2007) 提到:

you can create, load, and manipulate
the mappings programmatically



☆─────────────────────────────────────☆
  cute (小可爱) 于 (Thu Nov 15 20:11:31 2007) 提到:

he's goodbug's counterpart in the .net world



☆─────────────────────────────────────☆
  NeverLearn (Working Procedure) 于 (Fri Nov 16 19:54:38 2007) 提到:



☆─────────────────────────────────────☆
  depend (depend) 于 (Fri Nov 16 22:55:12 2007) 提到:

“容易”只是相对的,微软的东西out-of-box比较容易上手,但并不表示微软的产品

就可以很容易的调整到适合企业应用的程度。

拿Linq to Sql和NHibernate相比,Linq to Sql绝对比NHibernate容易上手,有非常

fancy的支持drag&drop的Designer,直接把table或者stored proc拖到窗口,马上就

自动生成class,立刻支持Linq语法进行数据库操作,Perfect!

但是如果想将这一套嵌入到现有系统里就没这么简单了。

1、100多个表,我不想一个一个drag,我需要script自动生成这些class和映射文件,

很好,微软提供了sqlmetal.exe,但是这个工具目前只能针对整个数据库工作,而不

能指定特定的表,今天生成了100个,明天加了一个表怎么办?全部生成一遍?那万一

我今天微调了class属性(比如删除了一些foreign key)或者某个列的生成方法,明天

数据定义变了,我重新生成一次这些文件岂不是把我以前的修改全覆盖了?到beta2为止

Linq to Sql还没有很好的解决办法。这个在稍微复杂一点的系统里面根本是不能接受
的。

2、我想生成指定的表对应的class,从而把每个class放在自己的文件里,这样更容易

维护,不行,除非你自己写工具生成class&mapping。

3、我不想要Sqlmetal生成那些臃肿的class,entity class就做entity class好了,我
不想

让他成为business object,不行,除非你自己写工具生成class。

4、我想为每个表生成的class指定特别的名字,比如以DB作为前缀,不行,除非你自己写

工具生成class&mapping。(BTW,sqlmetal处理单复数名词的方式相当幼稚,根本不能

handle以ES结尾的表名)

... ...

微软向我证实上述这些问题在release 1.0中不会得到解决。

熟悉NHibernate的人马上会发现上面的问题是多么熟悉,如果需要自己(第三方)来提供

这些工具的话,微软的“容易”体现在什么地方了?除非项目非常小,否则使用LtS 1.
0一

定会带来很严重的维护成本。

我上面所说的只是选择ORM方案需要考虑的诸多方面的一个而已,LtS的问题远远不止这
些,

比如微软几乎在同一时间推出LtS和EF两个ORM方案,二者关系不会像微软说得那么简单
吧,

微软会不会最终抛弃对其中一个的兼容呢(当然,不是真的不兼容,但是会用某种方法
迫使

你“升级”)?这种事情微软不是没干过。LtS和EF都是初来乍到,没有在业界得到太
多的

证明,而NHibernate的始祖Hibernate在Java community几乎已经成为ORM的工业标准了
,一

边是微软花里胡哨的Demo和市场推广(就像我一开始说的),另一方面则是大量成熟的
企业

级产品的背书,孰轻孰重?NHibernate/Hibernate是open source,没错这是把双刃剑
,有

能力的话可以对其进行针对性的扩充,但也很容易迷失在不完整的文档和讨论串之中,

如果想对微软的产品做一些改动,等几个版本升级能给你改就算运气不错了。

我不是MS Hater,但也不想成为微软市场营销的牺牲品,对于新的技术,还是应该

放到具体项目具体要求中全面评估,如果目前要我说LtS和NHibernate哪个好的话,

我的意见是“观望”,一方面是等EF,另一方面是看下一个版本的LtS能有什么改进,
同时

也要看NHibernate对于Linq的支持进展情况。



☆─────────────────────────────────────☆
  cute (小可爱) 于 (Fri Nov 16 23:02:06 2007) 提到:

赞。。



☆─────────────────────────────────────☆
  NeverLearn (Working Procedure) 于 (Sat Nov 17 02:52:51 2007) 提到:

I haven't tried LINQ on anything serious. My experience is from using
LLBLGEN PRO which is better than NHibernate. I firmly believe if a small
company can make LGP that fancy, there's no way M$ can do inferior.



☆─────────────────────────────────────☆
  NeverLearn (Working Procedure) 于 (Sat Nov 17 04:30:38 2007) 提到:



☆─────────────────────────────────────☆
  depend (depend) 于 (Sat Nov 17 10:30:21 2007) 提到:

关于你第一个例子,我对ASP.NET或者AJAX不是很熟悉,简单说说,你们有两个选择,

third-party->more feature->不兼容ajax.net

ASP.NET UI -> 兼容ajax.net but with less features,

显然你们对两种都不满意,所以从这个例子看不出微软的东西比third party的高明,

今天客户要ajax,你们觉得thrid party不支持ajax.net所以觉得还是用微软的好,

如果明天客户抱怨UI不友好,你们是不是又会觉得微软的东西没有third party的
feature

多呢?presentation layer在设计时就必须考虑到未来切换不同方案的可能性,如果

换起来困难,那是设计的问题,而不是工具的问题。

第二个例子,你说的web service support是指什么?是指直接将entity class作为

Schema/DataContract?且不说HN能不能做,从设计上讲,这就是一个非常大的缺陷,

将web service的contract直接和后台的数据定义绑定起来??如果后台数据定义

修改了怎么办?service的contract需要修改?所有service的client的代码也

需要修改?这根本是不可接受的。ORM就是ORM,这里面的O不应该是你的business

object,而只是数据的OO载体而已。

关于你的WCF问题,其实Linq to Sql刚开始出来的时候生成的entity class也不是

WCF ready的,所以你一样要等微软来升级或者提供新版本,要么就自己写工具生成

这些class。

和presentation layer一样,data access layer在设计的时候就必须要考虑到

以后的替换,必须将其与系统中的其他部分decouple,从这点上来说,讨论ORM

工具和service的兼容问题就是没有意义的,从ORM到business logic中间必须要

有抽象层。所以我们的business object和service schema都是独立设计和维护的,

不依赖于任何ORM工具。

很多时候,兼容不表示你就可以高枕无忧,比如今天Vista还是可以兼容win32的

程序,但是如果你想利用WPF的特性,你就必须要重写你的presnetation layer,

而等ajax.net 2.0出来以后,你是选择更新到2.0来使用更多特性还是继续在1.0

的“兼容”模式下开发呢?所以说兼容是个很虚幻的概念,再怎么兼容,技术进步

了,该改动该重写的地方还是要推倒重来,无论你用的是不是微软的东西。

时间仓促,好像有点离题了,大家将就着看吧。



☆─────────────────────────────────────☆
  cute (小可爱) 于 (Sat Nov 17 10:45:30 2007) 提到:

赞。。



☆─────────────────────────────────────☆
  NeverLearn (Working Procedure) 于 (Sat Nov 17 12:13:11 2007) 提到:



☆─────────────────────────────────────☆
  cute (小可爱) 于 (Sat Nov 17 12:45:00 2007) 提到:

也赞。。



☆─────────────────────────────────────☆
  depend (depend) 于 (Sat Nov 17 12:56:57 2007) 提到:

我忘了一个问题,你们有Infragistics的源码么,如果没有,那我觉得从一开始你们
选择Infragistics就有问题。在chase微软这个比赛上,谁能赢微软自己呢?

我想你我对web service的定义有区别,到底是谁在consume这个web service?

我猜你想说的是NH的不能很方便的生成你所需要的class和Xml schema?但是这就是
open source,out of box它不可能给你所有你要的feature,但是你可以很
灵活的进行修改。如果你们更喜欢商业产品的易用性和好的技术支持,我完全理解。
就我个人而言,我觉得我比别人更清楚自己想要什么和不想要什么,在力所能及的
范围里,让我自己做这些事情我会更安心。

比如你说的关于NH的例子,我没有用任何NH提供的工具来生成mapping和class,我是
用我自己的工具做的,我觉得这样生成的代码更有效率,自己以后调整的余地更大。

我想还是把话题扯回到NHibernate vs Linq to Sql上来,如果NH不是open source的,
我是一点都不会考虑的,而以Linq to Sql今天的程度,我也是不会考虑把它应用到
项目中去的。



☆─────────────────────────────────────☆
  cute (小可爱) 于 (Sat Nov 17 13:06:06 2007) 提到:

再赞一下。。



☆─────────────────────────────────────☆
  depend (depend) 于 (Sat Nov 17 13:07:30 2007) 提到:

别再赞了,发表一下看法啊


☆─────────────────────────────────────☆
  cogt (苦荆茶) 于 (Sat Nov 17 14:25:15 2007) 提到:

微软的东西对新手、小项目容易上手。如果是大点的项目,用open source的我觉得还放
心些,毕竟有code在手,自己能做些事情。不然只有指望升级。




☆─────────────────────────────────────☆
  les (Walk the walk, talk the talk) 于 (Sat Nov 17 14:37:15 2007) 提到:

1、100多个表,我不想一个一个drag,我需要script自动生成这些class和映射文件,

很好,微软提供了sqlmetal.exe,但是这个工具目前只能针对整个数据库工作,而不

能指定特定的表,今天生成了100个,明天加了一个表怎么办?全部生成一遍?那万一

我今天微调了class属性(比如删除了一些foreign key)或者某个列的生成方法,明天

数据定义变了,我重新生成一次这些文件岂不是把我以前的修改全覆盖了?到beta2为止

Linq to Sql还没有很好的解决办法。这个在稍微复杂一点的系统里面根本是不能接受
的。

这个partial class不能解决?







☆─────────────────────────────────────☆
  depend (depend) 于 (Sat Nov 17 15:34:40 2007) 提到:

可以部分解决,取决于你要修改什么,如果你想删除sqlmetal要生成的代码,那每次
sqlmetal还是会帮你加进去。我觉得如果sqlmetal能把每个表单独放到一个文件里,
维护会变得容易得多。



☆─────────────────────────────────────☆
  kanke (回家) 于 (Sat Nov 17 16:00:41 2007) 提到:

我们也是现在不知道怎么选择好。

我自己的一些比较小的项目我现在都用nettiers



☆─────────────────────────────────────☆
  kongzi (鸡龟骨滚羹) 于 (Sat Nov 17 16:27:33 2007) 提到:

open source的问题:
1.许多government agency不允许使用任何open source的东西
2.如果是很大的open source project(就是你不能自己maintain source),当出现升级
不兼容或缺少你需要的features时只能cross your finger to hope someday there
will be a solution.
M$的产品1.0基本上就是匆忙跟风占领一席之位;2.0基本可用;3.0相对成熟。所以要
make的decision是从何时开始使用M$的产品。如果1.0的version虽然有bugs或缺少
features,只要它的设计做的好(extensible),能通过某些途径解决我需要的东西,我还
是愿意从开始就用M$的产品。毕竟这样以后随着升级的问题会少些。

对于你自己能maintain的open source components/products, 通常会比microsoft的
couterparts更多feature,clean and efficient.这种情况完全没必要考虑M$的东西。
比如说log4net.

说到这里不得不提一下,不知道是不是M$招的太多fresh graduate的缘故。我觉得.net
的很多设计是拍脑袋想出来的,没有考虑工业界的应用(还是extensibilities). 举个
简单的例子,如果你用过.net的menu control做一些稍微复杂的应用你就应该有所体会
了。


☆─────────────────────────────────────☆
  depend (depend) 于 (Sat Nov 17 17:01:50 2007) 提到:

同意,不能维护的open source最好就别用了。

对于微软的拍脑袋做法我也深有体会,这也是为什么我觉得NH更能适应大型项目的
理由之一,毕竟Java community这么多应用是摆在那儿的。

另一个拍脑袋的例子是Enterprise Library,我用了2.0,发现里面大多数模块
根本是over complicated,非常之臃肿不灵活,.net community的feedback很少,
典型对比就是logging application block vs log4net,现在已经升级到3.1了,
但是用过2.0以后我就再也不想碰3.1了。

还有一个问题就是微软有意无意的误导或者隐藏问题细节,从最早期的一个几页长
的button.click函数,到最近很多的visual studio add-on(包括LtS的designer),
这些quick&dirty的东西很容易抓住眼球,但其实根本不适合规模较大的项目。
这也是我对微软新东西带有戒心的原因之一,不弄清楚了我是不敢用的。



☆─────────────────────────────────────☆
  NeverLearn (Working Procedure) 于 (Sat Nov 17 18:05:41 2007) 提到:

One thing I learnt over the years is that the other companies simply
don't have enough an edge to compete with M$ since they don't know the
internals. That's M$ own backyard. Take a look at the Borland C++, at
first they were like a storm and knocked MSC++ all over. But once Visual
C++ came out, they went down and could never come back. No one knew the
Windows platform better than M$, so of course Visual C++ dominated.

Now back to this NH thing, granted they may be better than LINQ for NOW
since they've been in this field longer. But at the end of the day, I
don't think they know .Net platform better than M$, and they probably
know even less about Sql Server. How do they fit in with the future .Net
versions is questionable. For one-off kinda solutions, you can take a
3rd-party short cut. For a long term .Net solution that really evolves,
you gotta wonder if you really want 3rd party stuff in the mix.



☆─────────────────────────────────────☆
  flyfire (flyfire) 于 (Sat Nov 17 20:41:17 2007) 提到:

microsoft product is good for small project and big project. open source is
good for mid-sized project. I remembered my first project after graduate is
to create a IVR (interactive voice representative) to handles about 2000-
3000 calls per hour. The first question is which voice package to use. At
that time, my boss said "do you think I will put whole department's calls on
an open source software?"



☆─────────────────────────────────────☆
  flyfire (flyfire) 于 (Sat Nov 17 20:53:21 2007) 提到:

NHibernate is not designed to work with SQL server only. So its performance
may not be the same as LINQ. The same problem for Java. That is why .NET is
still strong and will be stronger.




☆─────────────────────────────────────☆
  flyfire (flyfire) 于 (Sat Nov 17 20:55:43 2007) 提到:

I like log4net too. It is a great component.




☆─────────────────────────────────────☆
  flyfire (flyfire) 于 (Sun Nov 18 11:16:51 2007) 提到:

Seems you are very familiar with NH. One question here. Can I put NH queries
and ADO.NET queries into one transaction (doesn't matter the transaction is
NH or ADO.NET)?


☆─────────────────────────────────────☆
  depend (depend) 于 (Sun Nov 18 11:27:58 2007) 提到:

Google "enlist ADO commands into an NHibernate transaction"


☆─────────────────────────────────────☆
  NeverLearn (Working Procedure) 于 (Tue Nov 20 00:37:45 2007) 提到:



☆─────────────────────────────────────☆
  depend (depend) 于 (Tue Nov 20 18:36:50 2007) 提到:

that makes sense


[返回]
赞助链接
未名交友
将您的链接放在这儿
 

Site Map - Contact Us - Terms and Conditions - Privacy Policy

版权所有,未名空间(mitbbs.com),since 1996