• SOCKET调试工具与压力测试小工具源代码

    SOCKET 压力测试 UDP 日志接收。几年前写的,代码确实不咋地。

    4
    103
    91KB
    2008-02-27
    9
  • 基于AxWebBrowser开发的标签式浏览器源码

    由于一时的头脑发热,花了两个晚上基于AxWebBrowser写了一个浏览器MyIE。现在用这个浏览器发的帖子,有点小市民的成就感,嘿嘿。源代码可以在本人的资源里下载到,这里简单总结如下:<br><br>1、VS2005自带的WebBrowser功能较少(网上资源也不多),AxWebBrowser控件暴露的事件更多些。比如打开新窗口的控制,WebBrowser貌似没有简单的方法来实现。<br><br>2、实现标签式界面,难点有:1)所有标签共用一个地址条、状态条、导航按钮,要切换上下文,要把界面状态封装起来,我封装到 BrowserData 类里,寄存在 TabPage.Tag 属性里;2)关闭一个Tab页时,默认会激活第一个Tab页,而不会回到上一个标签,我设计了一个标签栈(_pageStack)来管理;<br><br>3、实现了状态条,赞叹VS2005的 ToolStrip 功能强大,使用起来太方便了!感谢为我们铺路的工作者们!<br><br>4、实现了收藏夹功能,跟IE实时同步,其实也很简单,就是打开 Favorite 目录,遍历目录和子目录,解析链接文件;另一个难题是调出 IE 界面,例如“Internet 选项”“整理收藏夹”“添加到收藏夹”等;<br><br>5、集成了Google、百度搜索。<br><br>6、实现了输入框的自动完成,跟IE的效果完全一致。这里再次赞叹 ToolStrip 控件的强大~~<br><br>7、实现了地址条输入框历史记录管理、搜索关键字历史记录管理<br><br>8、花的时间很短,bug很少,不过代码没什么注释,读者就费点眼神吧,呵呵 :-) <br>

    5
    165
    209KB
    2008-01-17
    17
  • AppFramework数据库访问组件_V1.2(带使用说明文档).rar

    修改了 V1.1/V1.0 的代码生成bug:当主键是字符串类型时,生成重复的DAO方法导致编译失败。修改了 TextParameter 类名为 TextField 保持命名风格统一。扩展了 IParamBase,增加了6个方法,使用起来跟方便,便于开发底层通用代码。

    5
    79
    1.27MB
    2008-01-13
    0
  • AppFramework数据库访问组件_V1.2.rar

    修改了 V1.1/V1.0 的代码生成bug:当主键是字符串类型时,生成重复的DAO方法导致编译失败。修改了 TextParameter 类名为 TextField 保持命名风格统一。扩展了 IParamBase,增加了发个方法,使用起来跟方便,便于开发底层通用代码。

    0
    109
    1004KB
    2008-01-13
    9
  • 本人原创的模拟星空的MFC源代码_Sky.RAR

    本人原创的模拟星空的MFC源代码

    5
    126
    220KB
    2008-01-11
    10
  • DiscuzNT_用AppFramework重写DataAccess层_源代码

    用 AppFramework 重写了 Discuz 论坛源码,作为学习 AppFramework 的样例。

    5
    71
    8.78MB
    2008-01-10
    0
  • SOCKET_压力测试与日志工具

    使用说明:<br><br>(1)目的<br>socket 基于 .Net Framework 1.1 开发,基于 socket 开发,可以发送和接收 TCP/UDP 包。<br>作者主要用于作服务器压力测试和日志接收。<br><br>(2)功能简介<br>界面上有两个 TAB 标签,一个发送一个接收。每个标签页上有上下两个大文本框,<br>上面的文本框用来输入发送信息,下面的文本框用来显示收到的信息。<br><br>(3)发送功能<br>例如在“发送”标签页,在上面文本框输入 HTTP 协议包文本,点击发送,会向服务器发送<br>信息,然后会在下面的文本框显示 Response,如果返回的是 UTF-8 编码,可以在菜单里选择 UTF-8 解码<br>从而解决乱码问题。发送有TCP/UDP/HTTP三种模式,TCP/UDP 只发不收,但HTTP会自动一发一收。<br><br>(4)接收功能<br>在“接收”标签页,上面文本框可以输入返回给客户端的信息,下面文本框用来显示从客户端接收到<br>的信息。接受有TCP/UDP两种模式。<br><br><br>(5)其他功能<br><br> 1、多线程发送功能,用于压力测试,在文件菜单里可以增加和减少或停止发送线程,还可以作线程计数<br> 2、文件菜单里有超时设置

    5
    334
    86KB
    2008-01-06
    16
  • AppFramework数据库访问组件_代码生成插件_V1.1.rar

    V1.1比V1.0增强了IDBSession功能,可查询得到 IDataReader;修改了查询 in 操作符的bug。<br>内含代码生成器,支持Oracle/SqlServer/MSAccess,ORMap性能大大优于iBatisNet,终身免费无限制使用,绝无任何版权问题。<br>===========<br>软件说明: <br>1.1 引言<br>约有90%的企业信息化管理系统基于数据库实现,这类系统中又有超过30%的代码集中在数据访问层负责业务数据存取。除了实现数据的增删改查,数据访问层还要提供一些与业务无关功能,例如面向对象的持久化与访问机制、本地事务与分布式事务支持、多数据库支持,这些机制或功能形成相对独立的逻辑领域,其主要目的有:<br><br>1、 提供简单易用的数据库访问方法,提高开发效率;<br><br>2、 提供面向对象的方式来简化对数据库访问与操作,也就是ORMap方式;<br><br>3、 屏蔽数据库差异,使开发出的产品容易在不同数据库产品上移植。<br><br>为了适应软件快速开发的需要,软件企业应该借助组件产品或开源软件项目来搭建这些基础设施。在.Net平台上,目前比较成功和应用较广的开源项目有NHibernate和IBatisNet等,它们在ORMap方面的表现尤为突出。依赖这些平台,软件开发效率和产品质量都得到了极大提高,ORMap机制渐渐成为大势所趋。<br><br>本公司致力于软件组件开发,提供的AppFramework数据库访问组件具有高效的ORMap机制,调用接口简单灵活,支持各种主流的数据库平台,是个非常优秀的数据访问组件。本文详尽描述了AppFramework数据库访问组件使用的方法和技巧,有助于开发者最大程度发挥出AppFramework的优势。<br><br>1.2 各种优秀ORMap工具比较<br>NHibernate和IBatisNet等虽然都实现了ORMap,但它们的设计侧重点有所不同,有着各自的优势和缺陷,适合于特定的项目。NHibernate实现了纯对象化的ORMap,在屏蔽数据库差异、面向对象方面做的非常好,但在访问与操作海量数据时其性能表现较差,也不易实现复杂的查询统计功能。NHibernate适合那些数据量不大、性能要求不高、复杂度不高的场合。<br><br>IBatisNet是一个轻量级ORMap工具,它把所有的SQL脚本以模板的方式集中到若干个XML配置文件里,用反射的方式向把C#类实体对象属性与SQL模板的参数绑定,动态生成参数化的SQL语句发送给数据库执行,查询的结果集也用反射的方式构造为对象集合返回给程序。由于提供了灵活的SQL模板机制,在海量数据的访问与操作方面其性能比NHibernate要高得多,也很容易实现各种复杂的数据查询统计功能。但是IBatisNet也存在许多几个不足之处,有些还是先天因素造成的:<br><br>第一,数据库可移植性差。IBatisNet获得高性能与灵活性也是付出代价的,它牺牲了数据库可移植性:由于编写SQL模板不得不用到数据库产品的一些语法差异,例如ORACLE的TO_DATE、Length()、SYSDATE等,为了把产品移植到其它数据库,开发人员不得不对大量的SQL模板进行翻译。<br><br>第二,无法方便地向数据库中插入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,即要求所有业务数据入库的值都不为空。但这样作实际上是限制了程序的行为能力,例如无法实现单据草稿的保存。<br><br>第三,在插入数据时无法方便的使用字段默认值。最明显的就是类似于LAST_UPDATE_TIME了,通常为了保证这个字段的一致性,通常在插入新记录时采用当前数据库时间作为字段值。但IBatisNet接收的实体类对象属性都是普通C#类型,并不具备传入表达式的能力。如果采用动态SQL,则会导致SQL模板和参数实体类过于复杂,将极大降低性能。<br><br>第四,在查询返回大量对象时,用反射的方式构造实体的方式性能损失是相当大的。实体类属性数目越多、返回记录数越多,用到反射的次数也越多,查询性能降低就越明显。<br><br>第五,不能方便地限定查询语句返回的字段。ADO.Net执行查询时,select语句里设置了几个字段就返回几个字段到DataTable。而IBatisNet若要返回不同的字段就要定义多套ResultMap,否则就定义一套所有字段的ResultMap,任何查询都返回所有字段。这样无疑浪费了数据库服务器与应用服务器之间的网络带宽,在进行海量数据访问时性能将严重降低。<br><br>第六,返回的结果IList不能够方便地进行二次查询。相比之下,ADO.Net返回的DataTable虽然性能差一些,但可以实现在应用程序内存中灵活和高性能的二次查询。<br><br>第七,无法直接利用数据库的特殊语法支持海量数据的分页查询功能。众所周知Oracle提供了ROWNUM实现数据数据库内分页功能,若要利用这一特性,就要在SQL模板里直接硬编码这些特殊语法,这必然导致大量的移植工作。<br><br>第八、缺少代码生成和检查工具。程序里的变量名与Sql模板里的变量经常会出现不一致,而这些错误无法在编译时发现,靠人工检查很容易造成错误泄漏。也没提供工具直接生成SQL模板和映射配置文件。<br><br>第九,IBatisNet的SqlMap文件里的SQL语句以明文存放,容易被修改造成重大安全隐患,尤其不适合开发C/S应用程序。<br><br>第十,由于Sql模板采用动态加载的方式,如果写错了SQL,程序里难以跟踪调试,这对初学者来说无疑是对耐心和信心的极大考验。<br><br>总之,IBatisNet虽然提灵活、高性能的ORMap机制,但却损失了数据库可移植性的,在使用方便性和局部性能方面也都有很大提高的余地。<br><br>1.3 AppFramework数据访问组件的组成和优势<br>AppFramework数据访问组件由下列文件组成:<br><br>1、 AppFramework.DBAccess.dll<br><br>提供多数据库统一的访问接口,提供DAO管理器、数据库会话管理器。<br><br>2、 AppFramework.Data.dll<br><br>提供核心的数据结构和基础类。<br><br>3、 AppFramework.Tools.CodeGenPlugin.msi<br><br>提供集成于Visual Studio 2005的C#代码生成器插件,用于生成DAO/Model/各种接口。<br><br>4、 DBAccess.config<br><br>配置数据库连接串。<br><br>5、 CodeGenPlogin.config<br><br>配置代码生成器参数。<br><br>6、 *.DaoGen文件<br><br>配置DAO生成信息,并由CodeGenPlugin解析生成代码。<br><br><br><br>AppFramework数据库访问组件针对IBatisNet的种种缺陷提出相应的解决方案,相比之下有如下优势:<br><br>1、 从扩展基础数据类型入手,解决了空值问题和默认值问题;<br><br>2、 提供了内置的数据库内分页访问机制,极大地提高了海量查询的响应速度;<br><br>3、 增加ObjectTable<T>泛型类来承载查询返回的对象集,不但比IList更加强类型化,还提供了二分查找功能,使得对象结果集可以在应用程序内存中进行重排序和快速查找;<br><br>4、 提供了强大的QueryFilter类构造查询条件,使得实现数据查询不再需要编写复杂的SQL语句;<br><br>5、 提供类似IBatisNet的Sql模板功能,为复杂的查询统计提供较直观的开发模式;<br><br>6、 提供代码生成工具,生成的类代码的同时可以类之间的继承关系和接口实现关系,所有DAO类方法均以接口作为参数,使得代码更加具有可扩展性和灵活性。<br><br>7、 Sql模板和ORMap直接生成.cs原代码,编译为可执行代码,各种ORMap映射文件无需再随主程序集一起部署,提高了代码的安全性,提高了代码的可调试性,也提高了ORMap的性能。<br><br><br><br>下面三张表格罗列的测试数据,可以明显看出AppFramework数据库访问组件的性能全面超越了IBatisNet: <br><br><br><br>表I –10并发20循环(数据库和测试机分开)<br><br>对比项目<br>iBatis2.0<br><br>(毫秒)<br>AppFramework<br><br>(毫秒)<br>后者前者性能对比<br><br>(倍)<br><br>根据主键获取实体<br><br>(20次单条select)<br>19.8<br>16.1<br><br>QueryFilter:18.0<br>1.23<br><br>1.10<br><br>每秒插入实体<br><br>(20次insert)<br>41<br>21<br>1.95<br><br>更新实体<br><br>(20次单条update)<br>27<br>19<br><br>SqlMap:24<br>1.42<br><br>1.13<br><br>查询结果集(平均101行)<br><br>(2循环200次select)<br>1100<br>690<br><br>不定字段:720<br>1.59<br><br>1.53<br><br><br><br><br>表II –50并发4循环(数据库和测试机分开)<br><br>对比项目<br>iBatis2.0<br><br>(毫秒)<br>AppFramework<br><br>(毫秒)<br>后者前者性能对比<br><br>(倍)<br><br>根据主键获取实体<br><br>(20次单条select)<br>17.5<br>13.3<br><br>QueryFilter:14.5<br>1.32<br><br>1.21<br><br>插入实体<br><br>(20次insert)<br>36.1<br>17.4<br>2.07<br><br>更新实体<br><br>(20次单条update)<br>23.5<br>15.9<br><br>SqlMap:20.3<br>1.48<br><br>1.16<br><br>查询结果集(平均101行)<br><br>(1循环200次select)<br>1055.1<br>666.8<br><br>不定字段:710.1<br>1.58<br><br>1.50<br><br><br><br><br>表III –50并发10循环(数据库和测试机同机)<br><br>对比项目<br>iBatis2.0<br><br>(毫秒)<br>AppFramework<br><br>(毫秒)<br>后者前者性能对比<br><br>(倍)<br><br>根据主键获取实体<br><br>(20次单条select)<br>6.1<br>5.3<br><br>QueryFilter: 5.75<br>1.15<br><br>1.06<br><br>插入实体<br><br>(20次insert)<br>15.1<br>10.8<br>1.40<br><br>更新实体<br><br>(20次单条update)<br>10.4<br>7.5<br><br>SqlMap:9.3<br>1.38<br><br>1.12<br><br>查询结果集(平均101行)<br><br>(1循环200次select)<br>560<br>360<br><br>不定字段:380<br>1.56<br><br>1.47<br><br><br><br><br>总之,AppFramework数据库访问组件是一个高性能、接口简单、可移植性强、高灵活性的综合数据访问解决方案。使用AppFramework数据库访问组件,可以降低企业的开发人员培训成本,提高产品的开发速度,提高产品稳定可靠性,提高产品的可伸缩性和可移植性。下文将分入门、精通、高级三个篇章,详细讲述如何使用AppFramework数据库访问组件来搭建应用程序。

    3
    250
    1.16MB
    2008-01-06
    20
  • AppFramework_V1.0_New

    代码生成器,ORMap,支持Oracle/SqlServer/MSAccess,性能大大优于iBatisNet,终身免费,随意使用。<br>===========<br>软件说明: <br>1.1 引言<br>约有90%的企业信息化管理系统基于数据库实现,这类系统中又有超过30%的代码集中在数据访问层负责业务数据存取。除了实现数据的增删改查,数据访问层还要提供一些与业务无关功能,例如面向对象的持久化与访问机制、本地事务与分布式事务支持、多数据库支持,这些机制或功能形成相对独立的逻辑领域,其主要目的有:<br><br>1、 提供简单易用的数据库访问方法,提高开发效率;<br><br>2、 提供面向对象的方式来简化对数据库访问与操作,也就是ORMap方式;<br><br>3、 屏蔽数据库差异,使开发出的产品容易在不同数据库产品上移植。<br><br>为了适应软件快速开发的需要,软件企业应该借助组件产品或开源软件项目来搭建这些基础设施。在.Net平台上,目前比较成功和应用较广的开源项目有NHibernate和IBatisNet等,它们在ORMap方面的表现尤为突出。依赖这些平台,软件开发效率和产品质量都得到了极大提高,ORMap机制渐渐成为大势所趋。<br><br>本公司致力于软件组件开发,提供的AppFramework数据库访问组件具有高效的ORMap机制,调用接口简单灵活,支持各种主流的数据库平台,是个非常优秀的数据访问组件。本文详尽描述了AppFramework数据库访问组件使用的方法和技巧,有助于开发者最大程度发挥出AppFramework的优势。<br><br>1.2 各种优秀ORMap工具比较<br>NHibernate和IBatisNet等虽然都实现了ORMap,但它们的设计侧重点有所不同,有着各自的优势和缺陷,适合于特定的项目。NHibernate实现了纯对象化的ORMap,在屏蔽数据库差异、面向对象方面做的非常好,但在访问与操作海量数据时其性能表现较差,也不易实现复杂的查询统计功能。NHibernate适合那些数据量不大、性能要求不高、复杂度不高的场合。<br><br>IBatisNet是一个轻量级ORMap工具,它把所有的SQL脚本以模板的方式集中到若干个XML配置文件里,用反射的方式向把C#类实体对象属性与SQL模板的参数绑定,动态生成参数化的SQL语句发送给数据库执行,查询的结果集也用反射的方式构造为对象集合返回给程序。由于提供了灵活的SQL模板机制,在海量数据的访问与操作方面其性能比NHibernate要高得多,也很容易实现各种复杂的数据查询统计功能。但是IBatisNet也存在许多几个不足之处,有些还是先天因素造成的:<br><br>第一,数据库可移植性差。IBatisNet获得高性能与灵活性也是付出代价的,它牺牲了数据库可移植性:由于编写SQL模板不得不用到数据库产品的一些语法差异,例如ORACLE的TO_DATE、Length()、SYSDATE等,为了把产品移植到其它数据库,开发人员不得不对大量的SQL模板进行翻译。<br><br>第二,无法方便地向数据库中插入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,即要求所有业务数据入库的值都不为空。但这样作实际上是限制了程序的行为能力,例如无法实现单据草稿的保存。<br><br>第三,在插入数据时无法方便的使用字段默认值。最明显的就是类似于LAST_UPDATE_TIME了,通常为了保证这个字段的一致性,通常在插入新记录时采用当前数据库时间作为字段值。但IBatisNet接收的实体类对象属性都是普通C#类型,并不具备传入表达式的能力。如果采用动态SQL,则会导致SQL模板和参数实体类过于复杂,将极大降低性能。<br><br>第四,在查询返回大量对象时,用反射的方式构造实体的方式性能损失是相当大的。实体类属性数目越多、返回记录数越多,用到反射的次数也越多,查询性能降低就越明显。<br><br>第五,不能方便地限定查询语句返回的字段。ADO.Net执行查询时,select语句里设置了几个字段就返回几个字段到DataTable。而IBatisNet若要返回不同的字段就要定义多套ResultMap,否则就定义一套所有字段的ResultMap,任何查询都返回所有字段。这样无疑浪费了数据库服务器与应用服务器之间的网络带宽,在进行海量数据访问时性能将严重降低。<br><br>第六,返回的结果IList不能够方便地进行二次查询。相比之下,ADO.Net返回的DataTable虽然性能差一些,但可以实现在应用程序内存中灵活和高性能的二次查询。<br><br>第七,无法直接利用数据库的特殊语法支持海量数据的分页查询功能。众所周知Oracle提供了ROWNUM实现数据数据库内分页功能,若要利用这一特性,就要在SQL模板里直接硬编码这些特殊语法,这必然导致大量的移植工作。<br><br>第八、缺少代码生成和检查工具。程序里的变量名与Sql模板里的变量经常会出现不一致,而这些错误无法在编译时发现,靠人工检查很容易造成错误泄漏。也没提供工具直接生成SQL模板和映射配置文件。<br><br>第九,IBatisNet的SqlMap文件里的SQL语句以明文存放,容易被修改造成重大安全隐患,尤其不适合开发C/S应用程序。<br><br>第十,由于Sql模板采用动态加载的方式,如果写错了SQL,程序里难以跟踪调试,这对初学者来说无疑是对耐心和信心的极大考验。<br><br>总之,IBatisNet虽然提灵活、高性能的ORMap机制,但却损失了数据库可移植性的,在使用方便性和局部性能方面也都有很大提高的余地。<br><br>1.3 AppFramework数据访问组件的组成和优势<br>AppFramework数据访问组件由下列文件组成:<br><br>1、 AppFramework.DBAccess.dll<br><br>提供多数据库统一的访问接口,提供DAO管理器、数据库会话管理器。<br><br>2、 AppFramework.Data.dll<br><br>提供核心的数据结构和基础类。<br><br>3、 AppFramework.Tools.CodeGenPlugin.msi<br><br>提供集成于Visual Studio 2005的C#代码生成器插件,用于生成DAO/Model/各种接口。<br><br>4、 DBAccess.config<br><br>配置数据库连接串。<br><br>5、 CodeGenPlogin.config<br><br>配置代码生成器参数。<br><br>6、 *.DaoGen文件<br><br>配置DAO生成信息,并由CodeGenPlugin解析生成代码。<br><br><br><br>AppFramework数据库访问组件针对IBatisNet的种种缺陷提出相应的解决方案,相比之下有如下优势:<br><br>1、 从扩展基础数据类型入手,解决了空值问题和默认值问题;<br><br>2、 提供了内置的数据库内分页访问机制,极大地提高了海量查询的响应速度;<br><br>3、 增加ObjectTable<T>泛型类来承载查询返回的对象集,不但比IList更加强类型化,还提供了二分查找功能,使得对象结果集可以在应用程序内存中进行重排序和快速查找;<br><br>4、 提供了强大的QueryFilter类构造查询条件,使得实现数据查询不再需要编写复杂的SQL语句;<br><br>5、 提供类似IBatisNet的Sql模板功能,为复杂的查询统计提供较直观的开发模式;<br><br>6、 提供代码生成工具,生成的类代码的同时可以类之间的继承关系和接口实现关系,所有DAO类方法均以接口作为参数,使得代码更加具有可扩展性和灵活性。<br><br>7、 Sql模板和ORMap直接生成.cs原代码,编译为可执行代码,各种ORMap映射文件无需再随主程序集一起部署,提高了代码的安全性,提高了代码的可调试性,也提高了ORMap的性能。<br><br><br><br>下面三张表格罗列的测试数据,可以明显看出AppFramework数据库访问组件的性能全面超越了IBatisNet: <br><br><br><br>表I –10并发20循环(数据库和测试机分开)<br><br>对比项目<br>iBatis2.0<br><br>(毫秒)<br>AppFramework<br><br>(毫秒)<br>后者前者性能对比<br><br>(倍)<br><br>根据主键获取实体<br><br>(20次单条select)<br>19.8<br>16.1<br><br>QueryFilter:18.0<br>1.23<br><br>1.10<br><br>每秒插入实体<br><br>(20次insert)<br>41<br>21<br>1.95<br><br>更新实体<br><br>(20次单条update)<br>27<br>19<br><br>SqlMap:24<br>1.42<br><br>1.13<br><br>查询结果集(平均101行)<br><br>(2循环200次select)<br>1100<br>690<br><br>不定字段:720<br>1.59<br><br>1.53<br><br><br><br><br>表II –50并发4循环(数据库和测试机分开)<br><br>对比项目<br>iBatis2.0<br><br>(毫秒)<br>AppFramework<br><br>(毫秒)<br>后者前者性能对比<br><br>(倍)<br><br>根据主键获取实体<br><br>(20次单条select)<br>17.5<br>13.3<br><br>QueryFilter:14.5<br>1.32<br><br>1.21<br><br>插入实体<br><br>(20次insert)<br>36.1<br>17.4<br>2.07<br><br>更新实体<br><br>(20次单条update)<br>23.5<br>15.9<br><br>SqlMap:20.3<br>1.48<br><br>1.16<br><br>查询结果集(平均101行)<br><br>(1循环200次select)<br>1055.1<br>666.8<br><br>不定字段:710.1<br>1.58<br><br>1.50<br><br><br><br><br>表III –50并发10循环(数据库和测试机同机)<br><br>对比项目<br>iBatis2.0<br><br>(毫秒)<br>AppFramework<br><br>(毫秒)<br>后者前者性能对比<br><br>(倍)<br><br>根据主键获取实体<br><br>(20次单条select)<br>6.1<br>5.3<br><br>QueryFilter: 5.75<br>1.15<br><br>1.06<br><br>插入实体<br><br>(20次insert)<br>15.1<br>10.8<br>1.40<br><br>更新实体<br><br>(20次单条update)<br>10.4<br>7.5<br><br>SqlMap:9.3<br>1.38<br><br>1.12<br><br>查询结果集(平均101行)<br><br>(1循环200次select)<br>560<br>360<br><br>不定字段:380<br>1.56<br><br>1.47<br><br><br><br><br>总之,AppFramework数据库访问组件是一个高性能、接口简单、可移植性强、高灵活性的综合数据访问解决方案。使用AppFramework数据库访问组件,可以降低企业的开发人员培训成本,提高产品的开发速度,提高产品稳定可靠性,提高产品的可伸缩性和可移植性。下文将分入门、精通、高级三个篇章,详细讲述如何使用AppFramework数据库访问组件来搭建应用程序。

    4
    176
    950KB
    2007-12-13
    10
  • AppFramework_V1.0

    1.1 引言<br>约有90%的企业信息化管理系统基于数据库实现,这类系统中又有超过30%的代码集中在数据访问层负责业务数据存取。除了实现数据的增删改查,数据访问层还要提供一些与业务无关功能,例如面向对象的持久化与访问机制、本地事务与分布式事务支持、多数据库支持,这些机制或功能形成相对独立的逻辑领域,其主要目的有:<br><br>1、 提供简单易用的数据库访问方法,提高开发效率;<br><br>2、 提供面向对象的方式来简化对数据库访问与操作,也就是ORMap方式;<br><br>3、 屏蔽数据库差异,使开发出的产品容易在不同数据库产品上移植。<br><br>为了适应软件快速开发的需要,软件企业应该借助组件产品或开源软件项目来搭建这些基础设施。在.Net平台上,目前比较成功和应用较广的开源项目有NHibernate和IBatisNet等,它们在ORMap方面的表现尤为突出。依赖这些平台,软件开发效率和产品质量都得到了极大提高,ORMap机制渐渐成为大势所趋。<br><br>本公司致力于软件组件开发,提供的AppFramework数据库访问组件具有高效的ORMap机制,调用接口简单灵活,支持各种主流的数据库平台,是个非常优秀的数据访问组件。本文详尽描述了AppFramework数据库访问组件使用的方法和技巧,有助于开发者最大程度发挥出AppFramework的优势。<br><br>1.2 各种优秀ORMap工具比较<br>NHibernate和IBatisNet等虽然都实现了ORMap,但它们的设计侧重点有所不同,有着各自的优势和缺陷,适合于特定的项目。NHibernate实现了纯对象化的ORMap,在屏蔽数据库差异、面向对象方面做的非常好,但在访问与操作海量数据时其性能表现较差,也不易实现复杂的查询统计功能。NHibernate适合那些数据量不大、性能要求不高、复杂度不高的场合。<br><br>IBatisNet是一个轻量级ORMap工具,它把所有的SQL脚本以模板的方式集中到若干个XML配置文件里,用反射的方式向把C#类实体对象属性与SQL模板的参数绑定,动态生成参数化的SQL语句发送给数据库执行,查询的结果集也用反射的方式构造为对象集合返回给程序。由于提供了灵活的SQL模板机制,在海量数据的访问与操作方面其性能比NHibernate要高得多,也很容易实现各种复杂的数据查询统计功能。但是IBatisNet也存在许多几个不足之处,有些还是先天因素造成的:<br><br>第一,数据库可移植性差。IBatisNet获得高性能与灵活性也是付出代价的,它牺牲了数据库可移植性:由于编写SQL模板不得不用到数据库产品的一些语法差异,例如ORACLE的TO_DATE、Length()、SYSDATE等,为了把产品移植到其它数据库,开发人员不得不对大量的SQL模板进行翻译。<br><br>第二,无法方便地向数据库中插入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,即要求所有业务数据入库的值都不为空。但这样作实际上是限制了程序的行为能力,例如无法实现单据草稿的保存。<br><br>第三,在插入数据时无法方便的使用字段默认值。最明显的就是类似于LAST_UPDATE_TIME了,通常为了保证这个字段的一致性,通常在插入新记录时采用当前数据库时间作为字段值。但IBatisNet接收的实体类对象属性都是普通C#类型,并不具备传入表达式的能力。如果采用动态SQL,则会导致SQL模板和参数实体类过于复杂,将极大降低性能。<br><br>第四,在查询返回大量对象时,用反射的方式构造实体的方式性能损失是相当大的。实体类属性数目越多、返回记录数越多,用到反射的次数也越多,查询性能降低就越明显。<br><br>第五,不能方便地限定查询语句返回的字段。ADO.Net执行查询时,select语句里设置了几个字段就返回几个字段到DataTable。而IBatisNet若要返回不同的字段就要定义多套ResultMap,否则就定义一套所有字段的ResultMap,任何查询都返回所有字段。这样无疑浪费了数据库服务器与应用服务器之间的网络带宽,在进行海量数据访问时性能将严重降低。<br><br>第六,返回的结果IList不能够方便地进行二次查询。相比之下,ADO.Net返回的DataTable虽然性能差一些,但可以实现在应用程序内存中灵活和高性能的二次查询。<br><br>第七,无法直接利用数据库的特殊语法支持海量数据的分页查询功能。众所周知Oracle提供了ROWNUM实现数据数据库内分页功能,若要利用这一特性,就要在SQL模板里直接硬编码这些特殊语法,这必然导致大量的移植工作。<br><br>第八、缺少代码生成和检查工具。程序里的变量名与Sql模板里的变量经常会出现不一致,而这些错误无法在编译时发现,靠人工检查很容易造成错误泄漏。也没提供工具直接生成SQL模板和映射配置文件。<br><br>第九,IBatisNet的SqlMap文件里的SQL语句以明文存放,容易被修改造成重大安全隐患,尤其不适合开发C/S应用程序。<br><br>第十,由于Sql模板采用动态加载的方式,如果写错了SQL,程序里难以跟踪调试,这对初学者来说无疑是对耐心和信心的极大考验。<br><br>总之,IBatisNet虽然提灵活、高性能的ORMap机制,但却损失了数据库可移植性的,在使用方便性和局部性能方面也都有很大提高的余地。<br><br>1.3 AppFramework数据访问组件的组成和优势<br>AppFramework数据访问组件由下列文件组成:<br><br>1、 AppFramework.DBAccess.dll<br><br>提供多数据库统一的访问接口,提供DAO管理器、数据库会话管理器。<br><br>2、 AppFramework.Data.dll<br><br>提供核心的数据结构和基础类。<br><br>3、 AppFramework.Tools.CodeGenPlugin.msi<br><br>提供集成于Visual Studio 2005的C#代码生成器插件,用于生成DAO/Model/各种接口。<br><br>4、 DBAccess.config<br><br>配置数据库连接串。<br><br>5、 CodeGenPlogin.config<br><br>配置代码生成器参数。<br><br>6、 *.DaoGen文件<br><br>配置DAO生成信息,并由CodeGenPlugin解析生成代码。<br><br> <br><br>AppFramework数据库访问组件针对IBatisNet的种种缺陷提出相应的解决方案,相比之下有如下优势:<br><br>1、 从扩展基础数据类型入手,解决了空值问题和默认值问题;<br><br>2、 提供了内置的数据库内分页访问机制,极大地提高了海量查询的响应速度;<br><br>3、 增加ObjectTable<T>泛型类来承载查询返回的对象集,不但比IList更加强类型化,还提供了二分查找功能,使得对象结果集可以在应用程序内存中进行重排序和快速查找;<br><br>4、 提供了强大的QueryFilter类构造查询条件,使得实现数据查询不再需要编写复杂的SQL语句;<br><br>5、 提供类似IBatisNet的Sql模板功能,为复杂的查询统计提供较直观的开发模式;<br><br>6、 提供代码生成工具,生成的类代码的同时可以类之间的继承关系和接口实现关系,所有DAO类方法均以接口作为参数,使得代码更加具有可扩展性和灵活性。<br><br>7、 Sql模板和ORMap直接生成.cs原代码,编译为可执行代码,各种ORMap映射文件无需再随主程序集一起部署,提高了代码的安全性,提高了代码的可调试性,也提高了ORMap的性能。<br><br> <br><br>下面三张表格罗列的测试数据,可以明显看出AppFramework数据库访问组件的性能全面超越了IBatisNet: <br><br> <br><br>表I –10并发20循环(数据库和测试机分开)<br><br>对比项目<br> iBatis2.0<br><br>(毫秒)<br> AppFramework<br><br>(毫秒)<br> 后者前者性能对比<br><br>(倍)<br> <br>根据主键获取实体<br><br>(20次单条select)<br> 19.8<br> 16.1<br><br>QueryFilter:18.0<br> 1.23<br><br>1.10<br> <br>每秒插入实体<br><br>(20次insert)<br> 41<br> 21<br> 1.95<br> <br>更新实体<br><br>(20次单条update)<br> 27<br> 19<br><br>SqlMap:24<br> 1.42<br><br>1.13<br> <br>查询结果集(平均101行)<br><br>(2循环200次select)<br> 1100<br> 690<br><br>不定字段:720<br> 1.59<br><br>1.53<br> <br><br> <br><br>表II –50并发4循环(数据库和测试机分开)<br><br>对比项目<br> iBatis2.0<br><br>(毫秒)<br> AppFramework<br><br>(毫秒)<br> 后者前者性能对比<br><br>(倍)<br> <br>根据主键获取实体<br><br>(20次单条select)<br> 17.5<br> 13.3<br><br>QueryFilter:14.5<br> 1.32<br><br>1.21<br> <br>插入实体<br><br>(20次insert)<br> 36.1<br> 17.4<br> 2.07<br> <br>更新实体<br><br>(20次单条update)<br> 23.5<br> 15.9<br><br>SqlMap:20.3<br> 1.48<br><br>1.16<br> <br>查询结果集(平均101行)<br><br>(1循环200次select)<br> 1055.1<br> 666.8<br><br>不定字段:710.1<br> 1.58<br><br>1.50<br> <br><br> <br><br>表III –50并发10循环(数据库和测试机同机)<br><br>对比项目<br> iBatis2.0<br><br>(毫秒)<br> AppFramework<br><br>(毫秒)<br> 后者前者性能对比<br><br>(倍)<br> <br>根据主键获取实体<br><br>(20次单条select)<br> 6.1<br> 5.3<br><br>QueryFilter: 5.75<br> 1.15<br><br>1.06<br> <br>插入实体<br><br>(20次insert)<br> 15.1<br> 10.8<br> 1.40<br> <br>更新实体<br><br>(20次单条update)<br> 10.4<br> 7.5<br><br>SqlMap:9.3<br> 1.38<br><br>1.12<br> <br>查询结果集(平均101行)<br><br>(1循环200次select)<br> 560<br> 360<br><br>不定字段:380<br> 1.56<br><br>1.47<br> <br><br> <br><br>总之,AppFramework数据库访问组件是一个高性能、接口简单、可移植性强、高灵活性的综合数据访问解决方案。使用AppFramework数据库访问组件,可以降低企业的开发人员培训成本,提高产品的开发速度,提高产品稳定可靠性,提高产品的可伸缩性和可移植性。下文将分入门、精通、高级三个篇章,详细讲述如何使用AppFramework数据库访问组件来搭建应用程序。 <br>

    0
    264
    950KB
    2007-12-13
    13
上传资源赚积分or赚钱