感觉ORM,现在的应用方向错了,错了,呜呜

小p啥时候回这来了 呵呵：）

撤了 都不知放哪个分类好了 难哪

这也放首页？

good

是的 所以我将大量的public改为internal 尤其是exe中
vs.net自带的不能用

如果在开始编写时就打算混淆,最好是Public Class通过调用internal或private class完成具体的功能.这样混淆起来就很轻松.
VS.NET带的Dotfuscator的混淆有bug,上次给他搞惨了.即使不重命名也会破坏某些方法的泛型返回参数.

可以公布一下测试结果，更直观！

添加上去了因为关联部分改为基础功能实现,修改后代码可能有点出入.
http://www.cnblogs.com/henryfan/archive/2007/07/29/835396.html

nhibernate 的性能长进得确不小,在一个月前跑测试还是令人失望的,想不到现在马上可以接受了,nhibernate.test.performance.dll就是自带的性能测试
选取其中的performancetest

Objects: 2 Direct ADO.NET: 3124980
Objects: 4 Direct ADO.NET: 468747
Objects: 8 Direct ADO.NET: 937494
Objects: 16 Direct ADO.NET: 781245
Objects: 32 Direct ADO.NET: 1562490
Objects: 64 Direct ADO.NET: 3124980
Objects: 128 Direct ADO.NET: 9374940
Objects: 256 Direct ADO.NET: 26406081
Objects: 512 Direct ADO.NET: 42343479
Objects: 1024 Direct ADO.NET: 93905649
Objects: 2048 Direct ADO.NET: 233279757
NHibernate: 44843463ms / Direct ADO.NET: 31874796ms = Ratio: 1.406863Objects: 2 - NHibernate: 156249
Objects: 4 - NHibernate: 312498
Objects: 8 - NHibernate: 468747
Objects: 16 - NHibernate: 1093743
Objects: 32 - NHibernate: 1718739
Objects: 64 - NHibernate: 3437478
Objects: 128 - NHibernate: 8281197
Objects: 256 - NHibernate: 14843655
Objects: 512 - NHibernate: 33749784
Objects: 1024 - NHibernate: 82499472
Objects: 2048 - NHibernate: 224373564
Objects 2 NHibernate: 156249ms / Direct ADO.NET: 468747ms = Ratio: 0.3333333
Objects 4 NHibernate: 468747ms / Direct ADO.NET: 468747ms = Ratio: 1
Objects 8 NHibernate: 937494ms / Direct ADO.NET: 781245ms = Ratio: 1.2
Objects 16 NHibernate: 781245ms / Direct ADO.NET: 781245ms = Ratio: 1
Objects 32 NHibernate: 1562490ms / Direct ADO.NET: 1406241ms = Ratio: 1.111111
Objects 64 NHibernate: 3281229ms / Direct ADO.NET: 2812482ms = Ratio: 1.166667
Objects 128 NHibernate: 7968699ms / Direct ADO.NET: 5937462ms = Ratio: 1.342105
Objects 256 NHibernate: 14687406ms / Direct ADO.NET: 12656169ms = Ratio: 1.160494
Objects 512 NHibernate: 33593535ms / Direct ADO.NET: 29999808ms = Ratio: 1.119792
Objects 1024 NHibernate: 96718131ms / Direct ADO.NET: 124686702ms = Ratio: 0.7756892
Objects 2048 NHibernate: 247654665ms / Direct ADO.NET: 219373596ms = Ratio: 1.128917

已修复NBearV3中的性能问题：http://www.cnblogs.com/teddyma/archive/2007/07/26/831646.html，请使用NBearV3的朋友下载最新的NBearV3.7.2.6版。

DLINQ只支持MSSQL,
呵呵,可能以后出正式版我也很难用到吧
把NH进行到底....

@江南白衣
抱歉,是笔误
意思是从june ctp 到beta 2对代码表面影响比较小

@jjx
beta1 和june ctp变化是很大
但beta2 和beta1的变化很小？？？
此话怎讲？beta和ctp之间的联系是什么？
我觉得变化应该是这样的：beta2 > june ctp > beta1

是这样嘛？

@kiler
Dlinq已经是板上钉钉的了，还会有什么悬念？

这样的测试结果并不具有代表性，因为软件是运行在复杂的环境中，而这种测试太过于单纯了

ding!

@随风流月
beta1 和june ctp变化是很大
但june ctp 和beta1的变化很小,最主要的是DataShape被取消,而用DataLoadOptions类代替

其它像GetChangeText之类的,对项目基本没有影响

加入HFSoft.Data的测试结果出来了,由于组件存在bug没有参与写操作.
http://www.cnblogs.com/henryfan/archive/2007/07/26/832160.html

其实很多Reflection都是可以用Emit或CodeDom来避免的。

其实这测的测试方式和直接条件读表是没有多大差别的.
对于是否要遍历读取来的数据跟组件没有多大关系,因为这些已经不属于数据库操作(不是组件的事情,用延时载加载处理例外).
等会给我的组件结果你看,希望看了以后不要觉得意外:)

@jjx
命名空间还是会变化的...
Beta 1 --> June CTP 就是一个例证。
Beta 2 之后应该会稳定下来。

linq to sql api应该不会大动了,我已经在june ctp上工作了近二周了,现在基本满意, 不过现在只能使用emacs+msbuild

DLinq还是算了，等出了正式版再研究吧，微软的东西没出正式版之前最好不要花时间研究，前面的ajax.net和objectspace就是最好的例子。

DLinq一出 无人争锋 不过现在没办法用啊 时间不等人 总不能项目和产品等到Dlinq正式推出后才进行吧

如果只是需要List进行databind 那么就没必要使用entitylist了, 我的做法是这样的

grid.datasource = products.table;

需要entitylist的主要是为了集合操作, 如find add insert indexat remove save...

比较乱。
不过为什么都没有 DLinq 测试？抗议中。。。

这个主要看返回lis类型和entity的类型(包括某些属性,像关系端)
如list类型是如果是内置的ArrayList或是List<Tentity> , entity 类型没有变化(nhibernate有时会用dynamic proxy和emit生成),那么测试就足可以参考

据我的观察,linq to sql 现在的tolist是可以说明这点的

还有一种方案是这样的，用Groupby,不过效率不高，能保证每条记录唯一性字段的情况下，也很准确

select * from
(
select * from (select top 20*4 唯一ID，其他字段 from 表集 where 条件 order by 排序) as a
union all
select * from (select top 20*5 唯一ID，其他字段 from 表集 where 条件 order by 排序) as b
)
a
group by 唯一ID，其他字段 having count(唯一ID)=1 order by 排序

我就就用两层top，容易理解。

mysql中的limit a,b 更加灵活...

个人认为“通用分页存储过程”是很不明智的“偷懒”
考虑数据量，查询复杂度，索引配合状况，结果集的散列程度，存储方式，等等，根本没有一劳永逸的方法。

这样的分页是用问题的,MS SQL有时会让你多几条记录
,比如每页20条,你可能会有时得到25条

又是分页...
正常来说分页不准已经是逻辑上的错误。
其实对于少量的数据分页其实根据没有必要计较用什么方法（小量数据体现不了差距）。可能有些人说那我有上千万的数据怎办，如果你把上千W的分页体现在应用上，那就容易产生数据库服务器安全问题;假设google做上千万或更多的分页结果页，那它可能面对一个非常严重的问题。

分析的很全面，:)

原来的两层top其实已经足够了。应该避免在非unique列上做分页。

sql server2000

本来就不是一个对 "Web 应用特性" 有任何优化的数据库。所以有很多地方很郁闷的如分页,因为 sql server2000 出来的时候Web还不是很火,多半的应用还是 win32 的天下哪

不过即使到了 SQL2005 row_number(),也没oracle 的
number 好用，哎......


期待 SQL2008 有所加强......

很有必要，虽然一般情况下看不出来分的对不对。

这点事还有必要说吗

学习

大侠呀，好久不见你在这里发文章了，www.progame.org也没了

学习了

临时表吧.

大不了再Stored Procedure中加上一个通过获得总页数判断是否是最后一页的好了。在数据量不是非常大的话，性能也不会有太大的影响。这是最直接的方式。

在这方面Oracle提供Rownum关键字就很好地解决了这个问题。

一直用这个方法，感觉还不错：SELECT TOP (PageSize) *
FROM table
WHERE (ID NOT IN
(SELECT TOP (PageSize * PageIndex) id
FROM table
ORDER BY field))
ORDER BY field

请发一份给我好吗？
hejiz@163.com

请EMAIL给我一份COPY，谢谢
vvrobinham@126.com

对了 如何 对 blob 结构 进行 直接操作，或是必须使用 base64 进行编码 才可以用吗？不知道 新的 sqlite3 如何进行 blob 操作！

sqlite 如何支持 二进制 的记录插入 修改，sqlite_encode_binary是能把 二进制 转换成 字符串吗？ 他会最大 扩大成 二倍吗？

select id from table_name limit 20 offset 40
选择的是41－60条记录

看到你给的一个“如何使用”中的例子，比对我的Kanas.net框架是的CRUD，我发现有几点不能满足你的要求，而且发现是你的要求中的一些不合理性，与你讨论。
一、没有与持久驱动相关的session，所有持久驱动都是全局级的，在应用域加载时一次性加载的，与会话无关。每个会话都使用同一份配置系统，每个需要持久的类型都必须与指定的持久驱动绑定。
二、没有用于处理持久Action的session，取而代之是一个应用相关的上下文AppContext。而且这个上下文没有可能自己创建，只能通过某个唯一对象来存取。这样的意义在于，在asp.net应用中，有可能一个持久事务是跨action甚至跨session的。这正是我不能接受大部分o/r mapping的关键之处。
三、我不能持久任何直接new的对象，这点远不如hibernate。我必须这样操作：