AppFramework-CSDN博客

原创 AppFramework最新版本V1.2安装包下载地址：http://download.csdn.net/source/334024【原V1.1/1.0版本的用户应尽快下载V1.2版】

安装包下载地址：http://download.csdn.net/source/334024 SOCKET 网络日志接收器下载地址：http://download.csdn.net/source/327016V1.2修改记录：1）修改了 V1.1/V1.0 的代码生成bug：当主键是字符串类型时，生成重复的DAO方法导致编译失败。2）修改了 TextParameter 类名为 Te

2007-12-18 10:01:00 7368 3

原创一个用双信号灯同步机制，协调两个后台线程的例子。

using System; using System.Collections.Generic; using System.ComponentModel; using System.Data; using System.Drawing; using System.Linq; using System.Text; using System.Windows.Forms; using System.Threading;<br

2010-08-26 00:13:00 1127

原创 JavaScript 的 Cross Site 脚本注入风险

今天有人来公司推销网站安全扫描软件，演示了对JS的跨域脚本注入风险的扫描，以前没意识到，今天有所了解。如果您的程序页面有以下情况，那么JS脚本注入的风险就很大： 1）页面打开时，URL 有某个参数，例如 XXPage.aspx?XXParam=XXValue2）aspx页面里有如下代码： var p = ""; 注入风险如下：1）黑客假冒网站身份发

2010-01-20 22:17:00 1912

原创设计文档写些什么才有用？

一些公司用CMMI做软件开发过程管理，对详细设计过程要求很高，需产出Rose设计模型，画出序列图、活动图等等。本意是为了让Rose设计模型对后续的编码有指导意义。但实际实施过程中发现效果不佳，一是有人不愿意认真写详细设计文档，二是有人不愿意看详细设计文档，问题如下： 1）当详细设计和编码人员实际为同一人时：既然是同一人，自己做事心里有数，整体想清楚了就开始编码，而不愿意写

2009-11-26 08:03:00 1994 2

原创从几个方面评价软件设计的合理性？

1、问题的提出很多程序员写程序，想到哪写到哪，缺乏一个整体规划。结果随着代码的堆积，软件内部结构就乱得一团糟。想要修改一个地方，影响这、影响那，牵一发而动全身。最后不得不重构，甚至从根基重构---直接推倒重来! 一个欠设计的系统会随着规模的扩大加速死亡；而一个设计考究的系统，则可以长久保持年轻，后期维护成本也会降低。 2、软件设计评价软件设计分为几个层面：框架级

2009-11-23 22:05:00 7284

原创一种分布式数据库同步方案

对于大型企业，业务分布在世界各地，为了改善当地业务服务能力，不得不在当地部署数据库以提高性能，而各个区域之间的数据交互或者同步，成为不可不面对的问题。其间要解决的技术问题主要有： 1、同步数据的提取。从数据库里提取出需要同步的数据，这包括增、删、改三类动作对数据造成的改变。在数据表安装触发器是提取同步数据的简单有效的手段，而且触发器对应用层而言是透明的，应用程序感觉不到触发器的存在。

2008-07-15 10:25:00 4521 1

原创用 Microsoft.mshtml.dll 和 WebClient 自己实现网页保存为 MHT 文件

相信大家经常用IE保存网页功能保存有价值的网页，但是IE的网页保存功能做的不是太好，经常会有些页面保存失败。我也深受其烦，好在本人是程序员，程序员最大的好处是会自己编软件。正好我自己开发了个多页签浏览的IE，于是便在其中增加了网页保存为MHT文件的功能。网页保存为MHT功能主要包含以下几个关键问题：1）修改所有相对链接为绝对链接；2）把网页内容连同包含的 JS、图片、CSS等文件下载到

2008-05-08 21:44:00 4738 5

原创用 WeifenLuo.WinFormsUI 实现 VS2005 风格的多页签浏览器

效果图：使用起来还比较简单，关键点说明：1）在主窗口客户区放置一个DockPanel，设置如下事件：// TAB切换时会触发的事件，在这里切换主窗口公用工具栏和状态条： dockPanel.ActiveDocumentChanged += new EventHandler(dockPanel_ActiveDocumentChanged);2）每个TAB标签实际上是一个Form，

2008-05-08 21:02:00 3265 9

原创最近用VS2005C#开发的IE内核多页签浏览器，支持多线程下载和在后台保存MHT

最近用VS2005C#开发的IE内核多页签浏览器，支持多线程下载和在后台保存MHT，名字还没定，请大家帮忙想个好名字吧：） 1. 总体界面：VS2005风格，渐变色工具条背景、四边停靠栏，多页签浏览：2．菜单：VS2005风格，注意看跟VS2005自带的ToolStrip显示有点不一样哦，主菜单背后有阴影，效果不错吧！嘿嘿。1）文件菜单支持保存网页，是在后台下载的，而不像I

2008-04-20 22:29:00 2847 7

原创利用 Monitor.TryEnter 来规避 .NET 线程死锁的源代码

在开发多线程的应用程序时，我们会大量用到 lock (...) {} 块。如果 lock 的对象比较多，非常容易发生死锁。死锁的发生很难预料，而且一旦发生在界面线程上，界面就不再刷新响和应用户输入；如果发生在后台线程，后台线程也就阻塞不工作了，死锁必然会导致应用程序不可用。在.NET里发生死锁的原因是什么？以 C# 为例，通常 lock 语句是被转化为对一个资源的无限长时间的等待，所以一旦资源

2008-04-06 03:12:00 4643 2

原创近期 IE 打开新浪搜狐网页 CPU 使用率高的解决方法

近期电脑不知道是感染了什么毛病，IE（6.0）只要打开新浪网页，CPU使用率就高达100%，并且在关闭IE的时候，CPU也会达到100%。找了很多帖子都没有解决方法，用各种杀毒软件、木马克星也找不到病毒和后门。有个帖子废话连篇，我试过都没用（还被多处转贴）。后来我发现“服务”管理器里有一个“Contrl Center of Storm Media”服务，好像是影音风暴(Stom) 安装上去的，把

2008-03-22 13:50:00 4220

原创截获IE控件下载事件并实现多线程断点续传下载总结

截获IE控件下载事件并实现多线程断点续传下载总结。1、截获IE的下载文件事件。有几个关键点：1）获取文件名；2）获取文件长度；3）决定是启动自己的多线程下载程序来下载文件还是继续让IE下载文件；4）注意容错；2、多线程下载的实现。要点如下：1）应对 referrer 防盗链验证；2）应对 Cookie 会话验证；3）应对 HttpWebRequest默认的只有2个并发连接限制；4）设置多线程分块5）写文件；参考代码：

2008-02-23 12:23:00 1956

原创介绍一个对IE控件封装最好的COM组件-csExWB

前段时间研究 IE 开发，在网上找了好久，终于找到一个叫做　csExWB 的组件。csExWB 分两个部分，一个部分是用 VC6 写的COM 组件，实现了包括 IDownloadManager 在内的诸多借口；第二部分是用 CSharp 写的，是对前面写的 COM 组件再做一次 .Net 封装。我用这个控件修改了自己的的 MyIE，代码少了很多，并且可以实现类似迅雷、Flashget 截获

2008-02-02 12:51:00 8605 3

原创对 WebBrowser 和 AxWebBrowser 两个控件使用经验的一点补充

几天前我写过一篇文章介绍使用 AxWebBrowser 控件作扩展， http://blog.csdn.net/AppFramework/archive/2008/01/16/2047610.aspx 。后来发现有些问题：1）打开HTML界面不是XP风格的平面式的，是老式的3D风格的。而用.Net自带的 WebBrowser 控件打开的页面是XP风格的。2）直接使用AxWebBrowser

2008-01-21 14:19:00 11829 5

原创基于AxWebBrowser实现完美的标签式浏览器，下载地址：http://download.csdn.net/source/337096

由于一时的头脑发热，花了两个晚上基于AxWebBrowser写了一个浏览器MyIE。现在用这个浏览器发的帖子，有点小市民的成就感，嘿嘿。源代码可以在本人的资源里下载到，下载地址：http://download.csdn.net/source/337096这里简单总结如下：1、VS2005自带的WebBrowser功能较少（网上资源也不多），AxWebBrowser控件暴露的事件更多些。

2008-01-16 22:20:00 8855 18

原创关于开闭原则的理解

开闭原则：设计一个模块的时候，应当使这个模块可以在不修改原有代码的前提下被扩展。这个原则是保证系统具有扩展性的基本原则。我理解有几个要点：1、要能够复用；2、扩展时只增加新方法、新类；3、不得不修改代码时，修改的范围必须是局部的、隐藏的；通常变更有三种方式，一种是横向变更，例如售票系统，原来只能售火车票，现在要可以售机票；第二种是纵向变更，例如在某个流程里插入新活动或跳过活动；第三种是局部

2008-01-13 11:54:00 1952 1

原创模拟星空的MFC源代码_Sky.RAR，下载地址：http://download.csdn.net/source/332601

http://download.csdn.net/source/332601 代码写得还是比较经典的，2002年用 C# 写了第一版，3年后用 C++ 重写。

2008-01-11 23:43:00 1850 1

原创用AppFramework重写Discuz数据访问层源代码

下载地址：http://download.csdn.net/source/331414 修改的地方主要有:1）在解决方案里增加了“Discuz.Data.AppFramework”项目2）AppFramework插件生成的代码放在“Discuz.Data.AppFramework”项目的GenerateCode目录下3）对论坛管理的数据访问类源代码ForumManage.cs做了重

2008-01-10 21:54:00 2199

原创对数据库事务处理代码通常写法的一点改进

通常数据库事务处理代码都采用如下的模式编写：打开数据库连接();try{ 开启事务(); 数据库操作1(); 数据库操作2(); ......; 数据库操作n(); 提交事务();}catch (Exception err){ 回滚事务(); throw err; // 重新抛出异常（导致异常的堆栈信息发生变化，无法知道原始异常所在位置，不利于调

2008-01-07 10:16:00 1619

原创用 AppFramework 替换 Discuz!NT 的数据库访问层

（一）分析DIscuz!NT 支持2种数据源，SqlServer和MSAccess，但其数据库访问层实际上已经支持了 MySQL，只是安装程序还未提供基于 MySQL 的。 Discuz!NT采用了"页面类 -> 业务类 -> 数据库访问类 -> DbHelper -> 数据库"这样的分层方式。数据库访问类有1个大接口3个大实现。所谓大接口就是 IDataProvider 接口，定义了9

2008-01-06 16:00:00 2156 3

原创 AppFramework1.0数据库访问组件使用说明(八)DAO类的使用

1.1 DAO类的使用在AppFramework里DAO类可以由代码生成工具自动生成，开发者只需要通过DAO类基本上就可以完成大部分增删查改业务，一些特殊的业务如果无法用DAO实现，则可以通过SqlMap结合IDBSession来实现。DAO主要处理三类对象：1、表：生成的代码有增删改查等方法；2、视图：生成的代码有查询方法；3、

2007-12-17 23:57:00 1275

原创 AppFramework1.0数据库访问组件使用说明(七)SqlTemplate与SqlMap的使用

1.1 SqlTemplate与SqlMap的使用1.1.1 SqlTemplate原理在早期做过报表系统开发的都知道，众多的查询条件和复杂的统计逻辑都直接硬编码在程序里，程序代码与SQL代码交织在一起，程序文件变得冗长杂乱，时间久了就变得难以维护。SqlTemplate是AppFramework提供的一种可视化、结构化的动态SQL语法，其代码为XML格式，从程序中剥离出来编写在

2007-12-17 23:54:00 1509

原创 AppFramework1.0数据库访问组件使用说明(六)QueryFilter的使用

1.1 QueryFilter的使用QueryFilter是AppFramework提供的一个功能强大、不需要编写SQL语句、跨数据库、参数化、执行性能优异的查询条件构造器。有了QueryFilter我们不需要再拼装SQL语句，不用再担心单引号导致SQL注入的安全漏洞，不用担心被众多的AND、OR、NOT等逻辑运算符弄得晕头转向，不用区分处理TO_DATE、UPPER等无法跨数据库的表

2007-12-17 23:44:00 4934 3

原创 AppFramework1.0数据库访问组件使用说明(五)IDBSession使用详解

1.1 IDBSession使用详解IDBSession负责与数据库打交道，它通过ADO.NET实现几种常用数据库的连接。目前支持3种数据库：SQLServer(7.0、2000、2005三个版本，推荐2005)、ORACLE（8.1.7以上，推荐9i）、MSAccess(需要MDAC1.7以上支持)。与IDBSession有关的关系图如下：

2007-12-17 23:40:00 2289

原创 AppFramework1.0数据库访问组件使用说明(四)基础数据类型

1.1 基础数据类型1.1.1 有关DBValue 为了规避IBatisNet的空值问题，AppFramework不使用C#基本类型来构造实体类。AppFramework对C#基本类型作了简单封装，增加了一个是否有值的属性来标志字段值是否非空。每一种基本的C#类型都有对应的DBValue对其进行封装。

2007-12-17 23:37:00 1259

原创 AppFramework1.0数据库访问组件使用说明(三)配置文件详解

1.1 配置文件详解1.1.1 在DBAccess.config配置多个数据源如果应用系统规模较大，有可能会使用多个数据源。AppFramework支持多个数据源，配置方法是在DBAccess.config里配置多个节点，并给每个数据源命名不同的名称。注意，为了提高性能，应该把最常用的数据源设置为默认数据源，在DataSource节点里把Default属性设置值为true，例如

2007-12-17 23:32:00 1251

原创 AppFramework1.0数据库访问组件使用说明(二)入门

2.1 安装1.1.1 软件环境要求已安装如下软件：1、安装了.Net Framework 2.02、安装了Visual Studio 20053、如果要访问MSAccess数据库，需安装了MDAC（1.7以上版本）4、如果要访问Oracle数据库，需安装了ODP.NET专业的开发人员一般都知道如何获取和安

2007-12-17 22:42:00 2386

原创 AppFramework通用数据库访问组件之来龙去脉

一、起因AppFramework，名字起得是有点大。我的原始目标是做个全面的企业应用程序框架，内容涵盖B/S、C/S结构，从UI到DA，其功能应该覆盖大部分 ApplicationBlocks 所包含的功能。整体思路还是采用拿来主义，从开源软件提取精华，组织装配出成熟好用的框架。但是数据访问无疑是最基础、最关键的问题，涉及到性能、稳定性、易用性、开发效率等诸多问题。在这方面，

2007-12-12 11:38:00 1635

原创 AppFramework1.0数据库访问组件使用说明(一)引言

1 概述1.1 引言约有90%的企业信息化管理系统基于数据库实现，这类系统中又有超过30%的代码集中在数据访问层负责业务数据存取。除了实现数据的增删改查，数据访问层还要提供一些与业务无关功能，例如面向对象的持久化与访问机制、本地事务与分布式事务支持、多数据库支持，这些机制或功能形成相对独立的逻辑领域，其主要目的有：1、提供简单易用的数据库访问方法，

2007-12-11 12:22:00 2029

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

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

2008-02-27

基于AxWebBrowser开发的标签式浏览器源码

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

2008-01-17

AppFramework数据库访问组件_V1.2(带使用说明文档).rar

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

2008-01-13

AppFramework数据库访问组件_V1.2.rar

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

2008-01-13

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

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

2008-01-11

DiscuzNT_用AppFramework重写DataAccess层_源代码

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

2008-01-10

SOCKET_压力测试与日志工具

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

2008-01-06

AppFramework数据库访问组件_代码生成插件_V1.1.rar

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<T>泛型类来承载查询返回的对象集，不但比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数据库访问组件来搭建应用程序。

2008-01-06

AppFramework_V1.0_New

代码生成器，ORMap，支持Oracle/SqlServer/MSAccess，性能大大优于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<T>泛型类来承载查询返回的对象集，不但比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数据库访问组件来搭建应用程序。

2007-12-13

AppFramework_V1.0

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<T>泛型类来承载查询返回的对象集，不但比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数据库访问组件来搭建应用程序。

2007-12-13

空空如也

TA创建的收藏夹 TA关注的收藏夹

TA关注的人