datagrid里,当字段为空值时的处理问题

annio 2005-07-12 12:25:52
从oracle数据库表读出的数据,绑定到datagrid

比如读出数据是这样:(其中行1字段2为空,即表中该字段值为空)

字段1 字段2
行1 a

行2 b e

我在ItemDataBound事件中处理:
if(e.Item.ItemType==ListItemType.Item || e.Item.ItemType==ListItemType.AlternatingItem)
{
if(e.Item.Cells[2].Length == 0)
{
处理1;
}
else
{
处理2;
}
}

但是运行时候发现,处理1不执行,2行记录都是执行处理2,也就是说字段2有空值,但却执行不到处理1。

可是,我读出结果集中行1字段2(即DataTable.Rows[0][1])的长度在Label中发现确实长度是0。可是为什么处理1执行不到?

我也试过用e.Item.Cells[2].Text == null
e.Item.Cells[2].Text == ""
e.Item.Cells[2].Text == null || e.Item.Cells[2].Text == ""

这3个条件也一样执行不到“处理1”!

怪事了
...全文
309 11 打赏 收藏 转发到动态 举报
写回复
用AI写文章
11 条回复
切换为时间正序
请发表友善的回复…
发表回复
annio 2005-07-12
  • 打赏
  • 举报
回复
声明:

上面所有的e.Item.Cells[2] 应该是 e.Item.Cells[1]

我写错了。

---------------------------------
各位帮我看看为什么执行不到“处理1”???


annio 2005-07-12
  • 打赏
  • 举报
回复
从一个朋友那里得到解释(ps:这个朋友还是女滴~~~)

用这个来判断

if(e.Item.Cells[2].Text.Trim() == " ")

她的解释如下:
datagrid在页面上显示出来后,空值转换为html,是 " "


ps:太强了!!!
daishengs 2005-07-12
  • 打赏
  • 举报
回复
在SQL语句中用isnull('a','')
syeerzy 2005-07-12
  • 打赏
  • 举报
回复
加个断点,给 (e.Item.Cells[1]) 添加一个监视,看看怎么回事,也有可能Cells[1]里面是个空格( )或是个其他html标签(<td></td>)???
annio 2005-07-12
  • 打赏
  • 举报
回复
(e.Item.Cells[1].text + "a" == "a") 这个方法也不行,


问题是连e.Item.Cells[2].Text.Length == 0这个方法来判断都不可以,而我试过,确实显示出来长度是0啊。

难道我是错在其它地方?
syeerzy 2005-07-12
  • 打赏
  • 举报
回复
if(e.Item.Cells[1].text + "a" == "a") 呵呵,够绝,收藏!
mylover002 2005-07-12
  • 打赏
  • 举报
回复
在db中先处理以下了:isnull('a','')
hchxxzx 2005-07-12
  • 打赏
  • 举报
回复
由于从数据库中读取出来的值,有两种表现空的形式,一种是"",没有值,一种是null,当你以如下方式进行判断的时候
if(xxx == "")
那么,值为null的,将不通过此判断,因为null并非等于"",所以,最简单的方式如下:
if(e.Item.Cells[1].text + "a" == "a")
这样可同时起到判断""和null的作用.
annio 2005-07-12
  • 打赏
  • 举报
回复
lxg13(翔子) 的方法可以,谢谢,一会马上揭帖


但我想问一下为什么我写的那些条件都不能判断到空值,

另:还有其它判断方法么?

谢谢!
祥子_13 2005-07-12
  • 打赏
  • 举报
回复
if(Convert.IsDBNull(DataBinder.Eval(e.Item.Data,"字段2")))
处理1;
else
处理2;
codeangel 2005-07-12
  • 打赏
  • 举报
回复
if(e.Item.Cells[1].Length == 0 && e.Item.Cells[1].text==null)
{
处理1;
}
else
{
处理2;
}
例行更新,不过本次有新组件加入,感觉这次的组件早就应该有了,居然到现在才加入进来,不管怎么说有总比没有好。这次还是以改进为主,改进项占了大多数。废话不多说具体内容大家看更新说明吧!另外由于经常收到chm格式文件无法用的反馈,其实不是无法用,只是要授权。虽然已经解释多遍,但是依然有人不知道,索性就取消chm格式的文档了,今后统一采用exe+pdf格式,由于目前尚无间制作pdf格式的api文档,所以1.5版中只有exe的,pdf格式将在下一版中提供。 jQuery EasyUI 1.5版本更新内容: Bug(修复) combobox:修复在加载包含所选项数据的候不会触发“onSelect”事件的BUG; datagrid:修复在字段设置为一个空值候导致在某些情况下“updateRow”方法无法正常工作的BUG。 Improvement(改进) 一个label标签可以被关联到任意表单的字段上; combobox:改进在下拉项中“select”和“unselect”的规则; combobox:添加“limitToList”属性来限制只能输入在列表项中的内容; combogrid:允许用户快速克隆组件; form:添加“dirty”属性,允许用户只发送变更的字段内容; form:添加“resetDirty”方法; datagrid:允许用户在没有数据的候显示一条消息(比如:无记录); textbox:添加“label”、“labelWidth”、“labelPosition”和“labelAlign”属性; spinner:添加“spinAlign”属性; calendar:允许用户在日历组件上显示周数(今年的第几周); window:添加“constrain”属性。 New Plugin(新组件) passwordbox:该插件允许用户在具有更好交互功能的输入框中输入密码; combotreegrid:该插件结合了combobox和treegrid组件。
一、升级说明 1、修复了数据库中字段值为空值候查询报错的Bug; 2、修复DbCommand属性ExecuteType为DbExecuteType.Scalar执行命令报错的Bug; 3、感谢网友“尘世流浪汉”和“春之子”反馈Bug,也欢迎大家试用并提出更多建议! 二、修复功能示例 1、空值测试 public class T_Test { public int? Id { get; set; } public string Name { get; set; } } try { //创建一个数据连接 DbConnection conn = new DbConnection("Data Source=|DataDirectory|CSmsPlatThird.db;Pooling=true;FailIfMissing=false"); //设置使用的数据访问程序集 conn.AssemblyName = "System.Data.SQLite"; //设置数据工厂,这是SQLite的数据工厂 conn.DbProviderFactory = "System.Data.SQLite.SQLiteFactory"; //创建一个数据命令 DbCommandSyn cmd = new DbCommandSyn(); //设置命令的连接 cmd.Connection = conn; //设置SQL语句,可以是存储过程 cmd.CommandText = "SELECT [Id],[Name] FROM [T_Test]"; //设置命令类型,一般SQL语句是Text,存储过程是StoredProcedure cmd.CommandType = DbCommandType.Text; //设置执行类型 cmd.ExecuteType = DbExecuteType.Reader; //执行命令,得到结果 DbCommandExecuteResult result = cmd.Execute(); if (!string.IsNullOrEmpty(result.ErrMsg))//首先判断ErrMsg是否有值,有表示执行过程发生错误 { MessageBox.Show("发生错误:" + result.ErrMsg); } else { List valueList = result.ReaderResult.ToEntityList(); //将数据显示在DataGrid中 this.dataGrid1.ItemsSource = valueList; } } catch (Exception ex) { MessageBox.Show("发生错误:" + ex.ToString()); } 2、存储过程示例 try { //数据库创建T_SQL脚本在网站App_Data文件夹下面,文件名为OMSDB.sql DbConnection conn = new DbConnection("Server=localhost;DataBase=OMSDB;Uid=sa;Pwd=jiton;"); DbCommandSyn cmd = new DbCommandSyn(); cmd.Connection = conn; //设置存储过程名称 cmd.CommandText = "JP_GetSystemName"; //设置命令类型为存储过程 cmd.CommandType = DbCommandType.StoredProcedure; cmd.ExecuteType = DbExecuteType.Scalar; //执行命令,得到结果 DbCommandExecuteResult result = cmd.Execute(); if (!string.IsNullOrEmpty(result.ErrMsg))//首先判断是否存在错误 { MessageBox.Show("发生错误:" + result.ErrMsg); } else { MessageBox.Show("系统名称为:" + result.ScalarResult as string); } } catch (Exception ex) { MessageBox.Show("发生错误:" + ex.Message); } 三、技术交流 有任何问题可以加入唯一指定的专用QQ群153079750进行反馈交流,也欢迎加入笔者的另一个Silverlight技术群175213051进行交流。
相当但丰富于DataTable/View数据王国的“BaiDu”超级搜索过滤(欢迎转载)。***用法***名称:淘金筛(超级搜索过滤器)***用法***Step1 将淘金筛控件拖至WinForm/WebForm,假如命名为GoldFilter1; 将网格控件拖至WinForm/WebForm,假如命名为DataGrid1;Step2 在Form_Load/Page_Load事件中过程中,设置DataGrid1的数据源之后,只需指定如下一句一切OK: GoldFilter1.DataSource = DataGrid1.DataSourceStep3 程序运行,GoldFilter1自动在WinForm/WebForm中为字段列下拉框加载数据源的各列或指定的列。 为操作类型下拉框加载各种操作,包括各种比较操作如=、<>、>、>=、<、<=、列举多个相等过滤、 两者之间范围比较等及其它的丰富的操作如包含、左包含、右包含模糊匹配。针对常用且实用的 长度判断、空值与非空值过滤特别智能匹配比较等。***功能特点*** 简单快捷、易用实用***功能描述*** 对DataTable/View各列做各种智能匹配、比较操作、模糊匹配查询过滤、在结果中查询过滤。 相当但丰富于DataTable/View数据王国的“BaiDu”***适用范围*** 各个网站网页或软件的网格数据过滤,通用于Oracel、SQLServer、ADO.NET的查询过滤。***操作*** 1、智能匹配 字段列下拉框选择一项,操作类型下拉框不用选,直接在过滤输入中输入过滤的数字或文本或日期即可查找过滤。 如果你输入了通配符如%、*号,自动做模糊匹配查找过滤。 2、比较操作 字段列下拉框选择一项,操作类型下拉框选择比较操作,直接在过滤输入中输入过滤的数字或文本或日期即可查找过滤。 比较操作有如下几种: 相等、不等、大于、大于或等于、小于、小于或等于、两者之间、列举多个(相等) 3、模糊匹配 字段列下拉框选择一项,操作类型下拉框选择包含操作,直接在过滤输入中输入包含的数字或文本或日期即可查找过滤。 包含操作有如下几种: 包含,过滤所有在过滤输入中的文本中出现的数据 左边象,过滤所有以在过滤输入中的文本开头的数据 右边象,过滤所有以在过滤输入中的文本结尾的数据 4、在结果中查询过滤 可以无限次重复使用前面操作后,执行在结果中查找命令。************************************************************************************************ 作 者:长江支流(周方勇) Email:flygoldfish@sina.com QQ:150439795 网 址:为保证本站下载量,请直接本站下载,可联系作者索取最新源码。 ★★★★★您可以免费使用此程序,但是请您完整保留此说明,以维护知识产权★★★★★************************************************************************************************
V1.1比V1.0增强了IDBSession功能,可查询得到 IDataReader;修改了查询 in 操作符的bug。
内含代码生成器,支持Oracle/SqlServer/MSAccess,ORMap性能大大优于iBatisNet,终身免费无限制使用,绝无任何版权问题
===========
软件说明:
1.1 引言
约有90%的企业信息化管理系统基于数据库实现,这类系统中又有超过30%的代码集中在数据访问层负责业务数据存取。除了实现数据的增删改查,数据访问层还要提供一些与业务无关功能,例如面向对象的持久化与访问机制、本地事务与分布式事务支持、多数据库支持,这些机制或功能形成相对独立的逻辑领域,其主要目的有:

1、 提供简单易用的数据库访问方法,提高开发效率;

2、 提供面向对象的方式来简化对数据库访问与操作,也就是ORMap方式;

3、 屏蔽数据库差异,使开发出的产品容易在不同数据库产品上移植。

为了适应软件快速开发的需要,软件企业应该借助组件产品或开源软件项目来搭建这些基础设施。在.Net平台上,目前比较成功和应用较广的开源项目有NHibernate和IBatisNet等,它们在ORMap方面的表现尤为突出。依赖这些平台,软件开发效率和产品质量都得到了极大提高,ORMap机制渐渐成为大势所趋。

本公司致力于软件组件开发,提供的AppFramework数据库访问组件具有高效的ORMap机制,调用接口简单灵活,支持各种主流的数据库平台,是个非常优秀的数据访问组件。本文详尽描述了AppFramework数据库访问组件使用的方法和技巧,有助于开发者最大程度发挥出AppFramework的优势。

1.2 各种优秀ORMap工具比较
NHibernate和IBatisNet等虽然都实现了ORMap,但它们的设计侧重点有所不同,有着各自的优势和缺陷,适合于特定的项目。NHibernate实现了纯对象化的ORMap,在屏蔽数据库差异、面向对象方面做的非常好,但在访问与操作海量数据其性能表现较差,也不易实现复杂的查询统计功能。NHibernate适合那些数据量不大、性能要求不高、复杂度不高的场合。

IBatisNet是一个轻量级ORMap工具,它把所有的SQL脚本以模板的方式集中到若干个XML配置文件,用反射的方式向把C#类实体对象属性与SQL模板的参数绑定,动态生成参数化的SQL语句发送给数据库执行,查询的结果集也用反射的方式构造为对象集合返回给程序。由于提供了灵活的SQL模板机制,在海量数据的访问与操作方面其性能比NHibernate要高得多,也很容易实现各种复杂的数据查询统计功能。但是IBatisNet也存在许多几个不足之处,有些还是先天因素造成的:

第一,数据库可移植性差。IBatisNet获得高性能与灵活性也是付出代价的,它牺牲了数据库可移植性:由于编写SQL模板不得不用到数据库产品的一些语法差异,例如ORACLE的TO_DATE、Length()、SYSDATE等,为了把产品移植到其它数据库,开发人员不得不对大量的SQL模板进行翻译。

第二,无法方便地向数据库中插入NULL值。因为IBatisNet是直接把C#的基本类型(如int/DateTime)插入到数据库中字段的。对于一些C#值类型,例如int,并没有NULL状态。于是不得不采用一些特殊的值来表示NULL,例如int.MinValue。IBatisNet数据映射器会自动把int.MinValue转换为NULL插入到数据库,而从数据库中获得NULL,也会转化为C#的int.MinValue。这样,程序就要对int.MinVaue这个值进行特殊处理,例如不能把int.MinValue直接显示在DataGrid或界面上。有一种规避的方法,就是避免向数据库插入NULL,即要求所有业务数据入库的值都不为空。但这样作实际上是限制了程序的行为能力,例如无法实现单据草稿的保存。

第三,在插入数据无法方便的使用字段默认值。最明显的就是类似于LAST_UPDATE_TIME了,通常为了保证这个字段的一致性,通常在插入新记录采用当前数据库间作为字段值。但IBatisNet接收的实体类对象属性都是普通C#类型,并不具备传入表达式的能力。如果采用动态SQL,则会导致SQL模板和参数实体类过于复杂,将极大降低性能。

第四,在查询返回大量对象,用反射的方式构造实体的方式性能损失是相当大的。实体类属性数目越多、返回记录数越多,用到反射的次数也越多,查询性能降低就越明显。

第五,不能方便地限定查询语句返回的字段。ADO.Net执行查询,select语句设置了几个字段就返回几个字段到DataTable。而IBatisNet若要返回不同的字段就要定义多套ResultMap,否则就定义一套所有字段的ResultMap,任何查询都返回所有字段。这样无疑浪费了数据库服务器与应用服务器之间的网络带宽,在进行海量数据访问性能将严重降低。

第六,返回的结果IList不能够方便地进行二次查询。相比之下,ADO.Net返回的DataTable虽然性能差一些,但可以实现在应用程序内存中灵活和高性能的二次查询。

第七,无法直接利用数据库的特殊语法支持海量数据的分页查询功能。众所周知Oracle提供了ROWNUM实现数据数据库内分页功能,若要利用这一特性,就要在SQL模板直接硬编码这些特殊语法,这必然导致大量的移植工作。

第八、缺少代码生成和检查工具。程序的变量名与Sql模板的变量经常会出现不一致,而这些错误无法在编译发现,靠人工检查很容易造成错误泄漏。也没提供工具直接生成SQL模板和映射配置文件。

第九,IBatisNet的SqlMap文件的SQL语句以明文存放,容易被修改造成重大安全隐患,尤其不适合开发C/S应用程序。

第十,由于Sql模板采用动态加载的方式,如果写错了SQL,程序难以跟踪调试,这对初学者来说无疑是对耐心和信心的极大考验。

总之,IBatisNet虽然提灵活、高性能的ORMap机制,但却损失了数据库可移植性的,在使用方便性和局部性能方面也都有很大提高的余地。

1.3 AppFramework数据访问组件的组成和优势
AppFramework数据访问组件由下列文件组成:

1、 AppFramework.DBAccess.dll

提供多数据库统一的访问接口,提供DAO管理器、数据库会话管理器。

2、 AppFramework.Data.dll

提供核心的数据结构和基础类。

3、 AppFramework.Tools.CodeGenPlugin.msi

提供集成于Visual Studio 2005的C#代码生成器插件,用于生成DAO/Model/各种接口。

4、 DBAccess.config

配置数据库连接串。

5、 CodeGenPlogin.config

配置代码生成器参数。

6、 *.DaoGen文件

配置DAO生成信息,并由CodeGenPlugin解析生成代码。



AppFramework数据库访问组件针对IBatisNet的种种缺陷提出相应的解决方案,相比之下有如下优势:

1、 从扩展基础数据类型入手,解决了空值问题和默认值问题

2、 提供了内置的数据库内分页访问机制,极大地提高了海量查询的响应速度;

3、 增加ObjectTable泛型类来承载查询返回的对象集,不但比IList更加强类型化,还提供了二分查找功能,使得对象结果集可以在应用程序内存中进行重排序和快速查找;

4、 提供了强大的QueryFilter类构造查询条件,使得实现数据查询不再需要编写复杂的SQL语句;

5、 提供类似IBatisNet的Sql模板功能,为复杂的查询统计提供较直观的开发模式;

6、 提供代码生成工具,生成的类代码的同可以类之间的继承关系和接口实现关系,所有DAO类方法均以接口作为参数,使得代码更加具有可扩展性和灵活性。

7、 Sql模板和ORMap直接生成.cs原代码,编译为可执行代码,各种ORMap映射文件无需再随主程序集一起部署,提高了代码的安全性,提高了代码的可调试性,也提高了ORMap的性能。



下面三张表格罗列的测试数据,可以明显看出AppFramework数据库访问组件的性能全面超越了IBatisNet:



表I –10并发20循环(数据库和测试机分开)

对比项目
iBatis2.0

(毫秒)
AppFramework

(毫秒)
后者前者性能对比

(倍)

根据主键获取实体

(20次单条select)
19.8
16.1

QueryFilter:18.0
1.23

1.10

每秒插入实体

(20次insert)
41
21
1.95

更新实体

(20次单条update)
27
19

SqlMap:24
1.42

1.13

查询结果集(平均101行)

(2循环200次select)
1100
690

不定字段:720
1.59

1.53




表II –50并发4循环(数据库和测试机分开)

对比项目
iBatis2.0

(毫秒)
AppFramework

(毫秒)
后者前者性能对比

(倍)

根据主键获取实体

(20次单条select)
17.5
13.3

QueryFilter:14.5
1.32

1.21

插入实体

(20次insert)
36.1
17.4
2.07

更新实体

(20次单条update)
23.5
15.9

SqlMap:20.3
1.48

1.16

查询结果集(平均101行)

(1循环200次select)
1055.1
666.8

不定字段:710.1
1.58

1.50




表III –50并发10循环(数据库和测试机同机)

对比项目
iBatis2.0

(毫秒)
AppFramework

(毫秒)
后者前者性能对比

(倍)

根据主键获取实体

(20次单条select)
6.1
5.3

QueryFilter: 5.75
1.15

1.06

插入实体

(20次insert)
15.1
10.8
1.40

更新实体

(20次单条update)
10.4
7.5

SqlMap:9.3
1.38

1.12

查询结果集(平均101行)

(1循环200次select)
560
360

不定字段:380
1.56

1.47




总之,AppFramework数据库访问组件是一个高性能、接口简单、可移植性强、高灵活性的综合数据访问解决方案。使用AppFramework数据库访问组件,可以降低企业的开发人员培训成本,提高产品的开发速度,提高产品稳定可靠性,提高产品的可伸缩性和可移植性。下文将分入门、精通、高级三个篇章,详细讲述如何使用AppFramework数据库访问组件来搭建应用程序。
1.1 引言
约有90%的企业信息化管理系统基于数据库实现,这类系统中又有超过30%的代码集中在数据访问层负责业务数据存取。除了实现数据的增删改查,数据访问层还要提供一些与业务无关功能,例如面向对象的持久化与访问机制、本地事务与分布式事务支持、多数据库支持,这些机制或功能形成相对独立的逻辑领域,其主要目的有:

1、 提供简单易用的数据库访问方法,提高开发效率;

2、 提供面向对象的方式来简化对数据库访问与操作,也就是ORMap方式;

3、 屏蔽数据库差异,使开发出的产品容易在不同数据库产品上移植。

为了适应软件快速开发的需要,软件企业应该借助组件产品或开源软件项目来搭建这些基础设施。在.Net平台上,目前比较成功和应用较广的开源项目有NHibernate和IBatisNet等,它们在ORMap方面的表现尤为突出。依赖这些平台,软件开发效率和产品质量都得到了极大提高,ORMap机制渐渐成为大势所趋。

本公司致力于软件组件开发,提供的AppFramework数据库访问组件具有高效的ORMap机制,调用接口简单灵活,支持各种主流的数据库平台,是个非常优秀的数据访问组件。本文详尽描述了AppFramework数据库访问组件使用的方法和技巧,有助于开发者最大程度发挥出AppFramework的优势。

1.2 各种优秀ORMap工具比较
NHibernate和IBatisNet等虽然都实现了ORMap,但它们的设计侧重点有所不同,有着各自的优势和缺陷,适合于特定的项目。NHibernate实现了纯对象化的ORMap,在屏蔽数据库差异、面向对象方面做的非常好,但在访问与操作海量数据其性能表现较差,也不易实现复杂的查询统计功能。NHibernate适合那些数据量不大、性能要求不高、复杂度不高的场合。

IBatisNet是一个轻量级ORMap工具,它把所有的SQL脚本以模板的方式集中到若干个XML配置文件,用反射的方式向把C#类实体对象属性与SQL模板的参数绑定,动态生成参数化的SQL语句发送给数据库执行,查询的结果集也用反射的方式构造为对象集合返回给程序。由于提供了灵活的SQL模板机制,在海量数据的访问与操作方面其性能比NHibernate要高得多,也很容易实现各种复杂的数据查询统计功能。但是IBatisNet也存在许多几个不足之处,有些还是先天因素造成的:

第一,数据库可移植性差。IBatisNet获得高性能与灵活性也是付出代价的,它牺牲了数据库可移植性:由于编写SQL模板不得不用到数据库产品的一些语法差异,例如ORACLE的TO_DATE、Length()、SYSDATE等,为了把产品移植到其它数据库,开发人员不得不对大量的SQL模板进行翻译。

第二,无法方便地向数据库中插入NULL值。因为IBatisNet是直接把C#的基本类型(如int/DateTime)插入到数据库中字段的。对于一些C#值类型,例如int,并没有NULL状态。于是不得不采用一些特殊的值来表示NULL,例如int.MinValue。IBatisNet数据映射器会自动把int.MinValue转换为NULL插入到数据库,而从数据库中获得NULL,也会转化为C#的int.MinValue。这样,程序就要对int.MinVaue这个值进行特殊处理,例如不能把int.MinValue直接显示在DataGrid或界面上。有一种规避的方法,就是避免向数据库插入NULL,即要求所有业务数据入库的值都不为空。但这样作实际上是限制了程序的行为能力,例如无法实现单据草稿的保存。

第三,在插入数据无法方便的使用字段默认值。最明显的就是类似于LAST_UPDATE_TIME了,通常为了保证这个字段的一致性,通常在插入新记录采用当前数据库间作为字段值。但IBatisNet接收的实体类对象属性都是普通C#类型,并不具备传入表达式的能力。如果采用动态SQL,则会导致SQL模板和参数实体类过于复杂,将极大降低性能。

第四,在查询返回大量对象,用反射的方式构造实体的方式性能损失是相当大的。实体类属性数目越多、返回记录数越多,用到反射的次数也越多,查询性能降低就越明显。

第五,不能方便地限定查询语句返回的字段。ADO.Net执行查询,select语句设置了几个字段就返回几个字段到DataTable。而IBatisNet若要返回不同的字段就要定义多套ResultMap,否则就定义一套所有字段的ResultMap,任何查询都返回所有字段。这样无疑浪费了数据库服务器与应用服务器之间的网络带宽,在进行海量数据访问性能将严重降低。

第六,返回的结果IList不能够方便地进行二次查询。相比之下,ADO.Net返回的DataTable虽然性能差一些,但可以实现在应用程序内存中灵活和高性能的二次查询。

第七,无法直接利用数据库的特殊语法支持海量数据的分页查询功能。众所周知Oracle提供了ROWNUM实现数据数据库内分页功能,若要利用这一特性,就要在SQL模板直接硬编码这些特殊语法,这必然导致大量的移植工作。

第八、缺少代码生成和检查工具。程序的变量名与Sql模板的变量经常会出现不一致,而这些错误无法在编译发现,靠人工检查很容易造成错误泄漏。也没提供工具直接生成SQL模板和映射配置文件。

第九,IBatisNet的SqlMap文件的SQL语句以明文存放,容易被修改造成重大安全隐患,尤其不适合开发C/S应用程序。

第十,由于Sql模板采用动态加载的方式,如果写错了SQL,程序难以跟踪调试,这对初学者来说无疑是对耐心和信心的极大考验。

总之,IBatisNet虽然提灵活、高性能的ORMap机制,但却损失了数据库可移植性的,在使用方便性和局部性能方面也都有很大提高的余地。

1.3 AppFramework数据访问组件的组成和优势
AppFramework数据访问组件由下列文件组成:

1、 AppFramework.DBAccess.dll

提供多数据库统一的访问接口,提供DAO管理器、数据库会话管理器。

2、 AppFramework.Data.dll

提供核心的数据结构和基础类。

3、 AppFramework.Tools.CodeGenPlugin.msi

提供集成于Visual Studio 2005的C#代码生成器插件,用于生成DAO/Model/各种接口。

4、 DBAccess.config

配置数据库连接串。

5、 CodeGenPlogin.config

配置代码生成器参数。

6、 *.DaoGen文件

配置DAO生成信息,并由CodeGenPlugin解析生成代码。



AppFramework数据库访问组件针对IBatisNet的种种缺陷提出相应的解决方案,相比之下有如下优势:

1、 从扩展基础数据类型入手,解决了空值问题和默认值问题

2、 提供了内置的数据库内分页访问机制,极大地提高了海量查询的响应速度;

3、 增加ObjectTable泛型类来承载查询返回的对象集,不但比IList更加强类型化,还提供了二分查找功能,使得对象结果集可以在应用程序内存中进行重排序和快速查找;

4、 提供了强大的QueryFilter类构造查询条件,使得实现数据查询不再需要编写复杂的SQL语句;

5、 提供类似IBatisNet的Sql模板功能,为复杂的查询统计提供较直观的开发模式;

6、 提供代码生成工具,生成的类代码的同可以类之间的继承关系和接口实现关系,所有DAO类方法均以接口作为参数,使得代码更加具有可扩展性和灵活性。

7、 Sql模板和ORMap直接生成.cs原代码,编译为可执行代码,各种ORMap映射文件无需再随主程序集一起部署,提高了代码的安全性,提高了代码的可调试性,也提高了ORMap的性能。



下面三张表格罗列的测试数据,可以明显看出AppFramework数据库访问组件的性能全面超越了IBatisNet:



表I –10并发20循环(数据库和测试机分开)

对比项目
iBatis2.0

(毫秒)
AppFramework

(毫秒)
后者前者性能对比

(倍)

根据主键获取实体

(20次单条select)
19.8
16.1

QueryFilter:18.0
1.23

1.10

每秒插入实体

(20次insert)
41
21
1.95

更新实体

(20次单条update)
27
19

SqlMap:24
1.42

1.13

查询结果集(平均101行)

(2循环200次select)
1100
690

不定字段:720
1.59

1.53




表II –50并发4循环(数据库和测试机分开)

对比项目
iBatis2.0

(毫秒)
AppFramework

(毫秒)
后者前者性能对比

(倍)

根据主键获取实体

(20次单条select)
17.5
13.3

QueryFilter:14.5
1.32

1.21

插入实体

(20次insert)
36.1
17.4
2.07

更新实体

(20次单条update)
23.5
15.9

SqlMap:20.3
1.48

1.16

查询结果集(平均101行)

(1循环200次select)
1055.1
666.8

不定字段:710.1
1.58

1.50




表III –50并发10循环(数据库和测试机同机)

对比项目
iBatis2.0

(毫秒)
AppFramework

(毫秒)
后者前者性能对比

(倍)

根据主键获取实体

(20次单条select)
6.1
5.3

QueryFilter: 5.75
1.15

1.06

插入实体

(20次insert)
15.1
10.8
1.40

更新实体

(20次单条update)
10.4
7.5

SqlMap:9.3
1.38

1.12

查询结果集(平均101行)

(1循环200次select)
560
360

不定字段:380
1.56

1.47




总之,AppFramework数据库访问组件是一个高性能、接口简单、可移植性强、高灵活性的综合数据访问解决方案。使用AppFramework数据库访问组件,可以降低企业的开发人员培训成本,提高产品的开发速度,提高产品稳定可靠性,提高产品的可伸缩性和可移植性。下文将分入门、精通、高级三个篇章,详细讲述如何使用AppFramework数据库访问组件来搭建应用程序。

62,074

社区成员

发帖
与我相关
我的任务
社区描述
.NET技术交流专区
javascript云原生 企业社区
社区管理员
  • ASP.NET
  • .Net开发者社区
  • R小R
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告

.NET 社区是一个围绕开源 .NET 的开放、热情、创新、包容的技术社区。社区致力于为广大 .NET 爱好者提供一个良好的知识共享、协同互助的 .NET 技术交流环境。我们尊重不同意见,支持健康理性的辩论和互动,反对歧视和攻击。

希望和大家一起共同营造一个活跃、友好的社区氛围。

试试用AI创作助手写篇文章吧