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

【在 f*****e 的大作中提到】
: anyone has experience with that?
avatar
l*s
3
写个总结给你发个大包子.:)

【在 d****d 的大作中提到】
: 正在尝试中,想从Nhibernate和Linq to Sql / Entity Framework 里选一个
avatar
f*e
4
问个问题呀。
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)

【在 d****d 的大作中提到】
: 正在尝试中,想从Nhibernate和Linq to Sql / Entity Framework 里选一个
avatar
d*d
5
在ORM里,business object是和数据库分开的,二者用一个映射文件连接,
因此,你可以把现有的business object和数据表对应起来,以后修改表结构的时候,
只需要修改那个映射文件就可以了,基于business object的代码不需要变动。
当然,经常遇到的情况是修改表结构的时候发现business object的定义也要改,
这个时候就business代码也就需要修改了。
你说的not strong typed是什么意思?让Nhibernate返回一个object然后再cast?

【在 f*****e 的大作中提到】
: 问个问题呀。
: 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)

avatar
d*d
6
目前ORM还没有正式在我们系统中使用,目前只在调研阶段,
我有时间的话可以纸上谈兵一下。

【在 l*s 的大作中提到】
: 写个总结给你发个大包子.:)
avatar
f*e
7
what's the difference between ORM and strong-typed dataset?
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.
avatar
N*n
8
Why use nhibernate while LINQ and Entity Framework are coming out?
M$ default product can only be better.

【在 f*****e 的大作中提到】
: anyone has experience with that?
avatar
a*x
9
呼唤好虫~~~

【在 N********n 的大作中提到】
: Why use nhibernate while LINQ and Entity Framework are coming out?
: M$ default product can only be better.

avatar
d*d
10
我不太喜欢Linq To Sql,自带的工具可调参数太少,用户很难把它集成到现有系统中
去,
我问过微软的人,他们也同意这些问题,但是在第一个release里不会有太大的改进。
EF没怎么用过,不予评论。
喜欢NHibernate是因为它是open source,不满意的地方可以自己改。
你的第二句话是认真的还是开玩笑?

【在 N********n 的大作中提到】
: Why use nhibernate while LINQ and Entity Framework are coming out?
: M$ default product can only be better.

avatar
c*e
11
you can create, load, and manipulate
the mappings programmatically

net
候,

【在 f*****e 的大作中提到】
: what's the difference between ORM and strong-typed dataset?
: 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.

avatar
c*e
12
he's goodbug's counterpart in the .net world

【在 d****d 的大作中提到】
: 我不太喜欢Linq To Sql,自带的工具可调参数太少,用户很难把它集成到现有系统中
: 去,
: 我问过微软的人,他们也同意这些问题,但是在第一个release里不会有太大的改进。
: EF没怎么用过,不予评论。
: 喜欢NHibernate是因为它是open source,不满意的地方可以自己改。
: 你的第二句话是认真的还是开玩笑?

avatar
N*n
13

No it's from experience. With M$ default product, integration is always
easier than getting a third-party tool involved.

【在 d****d 的大作中提到】
: 我不太喜欢Linq To Sql,自带的工具可调参数太少,用户很难把它集成到现有系统中
: 去,
: 我问过微软的人,他们也同意这些问题,但是在第一个release里不会有太大的改进。
: EF没怎么用过,不予评论。
: 喜欢NHibernate是因为它是open source,不满意的地方可以自己改。
: 你的第二句话是认真的还是开玩笑?

avatar
d*d
14
“容易”只是相对的,微软的东西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还没有很好的解决办法。这个在稍微复杂一点的系统里面

【在 N********n 的大作中提到】
:
: No it's from experience. With M$ default product, integration is always
: easier than getting a third-party tool involved.

avatar
c*e
15
赞。。

为止
己写
提供
1.

【在 d****d 的大作中提到】
: “容易”只是相对的,微软的东西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)或者某个列的生成方法,明天

avatar
N*n
16
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.

beta2
First of all, any 微调 you listed can be done in LGP, and I believe
微调 by modifying the generated mapping code is questionable practice.
You shouldn't touch it, you should 微调 with the tool and then run
code generator to produce the new mapping code. In LGP, you run the
mapper to coll

【在 d****d 的大作中提到】
: “容易”只是相对的,微软的东西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)或者某个列的生成方法,明天

avatar
N*n
17

You have some excellent pts above. And ironically, "兼容" was #1 reason
why I prefer M$ default to third-party options. When building an
enterprise application, you'd like to see every component is from one
solution package. If one of them is from a third-party, you're gonna
see "兼容" problems. Let me give you two real examples.
1. Infragistics for ASP.NET. This thing looked fancy and offered quite
some features default ASPNET controls don't have. One of our guy used it
for a project and earlier t

【在 d****d 的大作中提到】
: “容易”只是相对的,微软的东西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)或者某个列的生成方法,明天

avatar
d*d
18
关于你第一个例子,我对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直接和后台的数据定义绑定起来??如果后台数据定义
修改了怎么

【在 N********n 的大作中提到】
:
: You have some excellent pts above. And ironically, "兼容" was #1 reason
: why I prefer M$ default to third-party options. When building an
: enterprise application, you'd like to see every component is from one
: solution package. If one of them is from a third-party, you're gonna
: see "兼容" problems. Let me give you two real examples.
: 1. Infragistics for ASP.NET. This thing looked fancy and offered quite
: some features default ASPNET controls don't have. One of our guy used it
: for a project and earlier t

avatar
c*e
19
赞。。

【在 d****d 的大作中提到】
: 关于你第一个例子,我对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作为

avatar
N*n
20

If you are using M$ default and there'll be future upgrade, more often than
not, your current code will cooperate with the upgrade. It's quite easy for
M$ to, say, sit the Asp.Net team and Ajax.net team together to sort out any
issues. With 3rd-party, you don't have this luxury. They don't know how M$
designs their stuff. That's why they tend to be thrown off by these changes.
The more we used Infragistics, the clearer we saw why M$ didn't implement
certain features. If they had, it simply woul

【在 d****d 的大作中提到】
: 关于你第一个例子,我对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作为

avatar
c*e
21
也赞。。

择,
明,
than
for
any
changes.
rich
陷,

【在 N********n 的大作中提到】
:
: If you are using M$ default and there'll be future upgrade, more often than
: not, your current code will cooperate with the upgrade. It's quite easy for
: M$ to, say, sit the Asp.Net team and Ajax.net team together to sort out any
: issues. With 3rd-party, you don't have this luxury. They don't know how M$
: designs their stuff. That's why they tend to be thrown off by these changes.
: The more we used Infragistics, the clearer we saw why M$ didn't implement
: certain features. If they had, it simply woul

avatar
d*d
22
我忘了一个问题,你们有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今天的程度,我也

【在 N********n 的大作中提到】
:
: If you are using M$ default and there'll be future upgrade, more often than
: not, your current code will cooperate with the upgrade. It's quite easy for
: M$ to, say, sit the Asp.Net team and Ajax.net team together to sort out any
: issues. With 3rd-party, you don't have this luxury. They don't know how M$
: designs their stuff. That's why they tend to be thrown off by these changes.
: The more we used Infragistics, the clearer we saw why M$ didn't implement
: certain features. If they had, it simply woul

avatar
c*e
23
再赞一下。。

M$
implement
clearly
a

【在 d****d 的大作中提到】
: 我忘了一个问题,你们有Infragistics的源码么,如果没有,那我觉得从一开始你们
: 选择Infragistics就有问题。在chase微软这个比赛上,谁能赢微软自己呢?
: 我想你我对web service的定义有区别,到底是谁在consume这个web service?
: 我猜你想说的是NH的不能很方便的生成你所需要的class和Xml schema?但是这就是
: open source,out of box它不可能给你所有你要的feature,但是你可以很
: 灵活的进行修改。如果你们更喜欢商业产品的易用性和好的技术支持,我完全理解。
: 就我个人而言,我觉得我比别人更清楚自己想要什么和不想要什么,在力所能及的
: 范围里,让我自己做这些事情我会更安心。
: 比如你说的关于NH的例子,我没有用任何NH提供的工具来生成mapping和class,我是
: 用我自己的工具做的,我觉得这样生成的代码更有效率,自己以后调整的余地更大。

avatar
d*d
24
别再赞了,发表一下看法啊

【在 c**e 的大作中提到】
: 再赞一下。。
:
: M$
: implement
: clearly
: a

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

【在 d****d 的大作中提到】
: 我不太喜欢Linq To Sql,自带的工具可调参数太少,用户很难把它集成到现有系统中
: 去,
: 我问过微软的人,他们也同意这些问题,但是在第一个release里不会有太大的改进。
: EF没怎么用过,不予评论。
: 喜欢NHibernate是因为它是open source,不满意的地方可以自己改。
: 你的第二句话是认真的还是开玩笑?

avatar
l*s
26
1、100多个表,我不想一个一个drag,我需要script自动生成这些class和映射文件,
很好,微软提供了sqlmetal.exe,但是这个工具目前只能针对整个数据库工作,而不
能指定特定的表,今天生成了100个,明天加了一个表怎么办?全部生成一遍?那万一
我今天微调了class属性(比如删除了一些foreign key)或者某个列的生成方法,明天
数据定义变了,我重新生成一次这些文件岂不是把我以前的修改全覆盖了?到beta2为止
Linq to Sql还没有很好的解决办法。这个在稍微复杂一点的系统里面根本是不能接受
的。
这个partial class不能解决?
avatar
d*d
27
可以部分解决,取决于你要修改什么,如果你想删除sqlmetal要生成的代码,那每次
sqlmetal还是会帮你加进去。我觉得如果sqlmetal能把每个表单独放到一个文件里,
维护会变得容易得多。

为止

【在 l*s 的大作中提到】
: 1、100多个表,我不想一个一个drag,我需要script自动生成这些class和映射文件,
: 很好,微软提供了sqlmetal.exe,但是这个工具目前只能针对整个数据库工作,而不
: 能指定特定的表,今天生成了100个,明天加了一个表怎么办?全部生成一遍?那万一
: 我今天微调了class属性(比如删除了一些foreign key)或者某个列的生成方法,明天
: 数据定义变了,我重新生成一次这些文件岂不是把我以前的修改全覆盖了?到beta2为止
: Linq to Sql还没有很好的解决办法。这个在稍微复杂一点的系统里面根本是不能接受
: 的。
: 这个partial class不能解决?

avatar
k*e
28
我们也是现在不知道怎么选择好。
我自己的一些比较小的项目我现在都用nettiers

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

avatar
k*i
29
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$的东西。
比如说

【在 d****d 的大作中提到】
: 我忘了一个问题,你们有Infragistics的源码么,如果没有,那我觉得从一开始你们
: 选择Infragistics就有问题。在chase微软这个比赛上,谁能赢微软自己呢?
: 我想你我对web service的定义有区别,到底是谁在consume这个web service?
: 我猜你想说的是NH的不能很方便的生成你所需要的class和Xml schema?但是这就是
: open source,out of box它不可能给你所有你要的feature,但是你可以很
: 灵活的进行修改。如果你们更喜欢商业产品的易用性和好的技术支持,我完全理解。
: 就我个人而言,我觉得我比别人更清楚自己想要什么和不想要什么,在力所能及的
: 范围里,让我自己做这些事情我会更安心。
: 比如你说的关于NH的例子,我没有用任何NH提供的工具来生成mapping和class,我是
: 用我自己的工具做的,我觉得这样生成的代码更有效率,自己以后调整的余地更大。

avatar
d*d
30
同意,不能维护的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的东西很容易抓住眼球,但其实根本不适合规模较大的项目。
这也是我对微软新东西带有戒心的原因之一,不弄清楚了我是不敢用的。

【在 k****i 的大作中提到】
: 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的

avatar
N*n
31
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

【在 k****i 的大作中提到】
: 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的

avatar
f*e
32
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?"

还放

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

avatar
f*e
33
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.

【在 N********n 的大作中提到】
: 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

avatar
f*e
34
I like log4net too. It is a great component.

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

【在 k****i 的大作中提到】
: 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的

avatar
f*e
35
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)?

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

avatar
d*d
36
Google "enlist ADO commands into an NHibernate transaction"

queries
is

【在 f*****e 的大作中提到】
: 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)?

avatar
N*n
37

performance
is
btw, my inside source told me M$ likes EF better than LINQ.

【在 f*****e 的大作中提到】
: 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.

avatar
d*d
38
that makes sense

【在 N********n 的大作中提到】
:
: performance
: is
: btw, my inside source told me M$ likes EF better than LINQ.

相关阅读
logo
联系我们隐私协议©2024 redian.news
Redian新闻
Redian.news刊载任何文章,不代表同意其说法或描述,仅为提供更多信息,也不构成任何建议。文章信息的合法性及真实性由其作者负责,与Redian.news及其运营公司无关。欢迎投稿,如发现稿件侵权,或作者不愿在本网发表文章,请版权拥有者通知本网处理。