网络架构：TCP/HTTP(https)/INI（亚XML）
介绍见：http://www.ccw.com.cn/htm/center/net/02_4_9_17.asp
运行模式：客户端动态加载服务器上的pas/dfm（文件或流）实现具体的业务操作界面
介绍见：http://liwei.csdn.net/Forum/topic.aspx?topicid=677&total=76&page=4
http://szhaitao.blog.hexun.com/12121564_d.html
http://szhaitao.blog.hexun.com/8872169_d.html
介绍一下我的MIS框架。。。。。。。。
网络架构：TCP/HTTP(https)/INI（亚XML）
介绍见：http://www.ccw.com.cn/htm/center/net/02_4_9_17.asp
运行模式：客户端动态加载服务器上的pas/dfm（文件或流）实现具体的业务操作界面
介绍见：http://liwei.csdn.net/Forum/topic.aspx?topicid=677&total=76&page=4
数据库实现模式：
以抽象的各人的待办事宜为主线，它的每一条记录就是一个工作任务（task,相当于工作模板form的一个实例）
记载了：
本任务的当前办事者（开始可能为空，即多个人都可以办，但是谁也没选中它确定由自己来办）
本任务所属的工作模板（form,一个业务流程里的具体一个步骤界面），它将决定了用户的操作界面和业务逻辑
本任务所对应的具体业务表（table，只是为了冗余。一般form定了，它对应的pas就固定了操作的业务数据表）
本任务所对应的业务记录ID（在具体业务表中，一个业务可能涉及多个表、多条记录，但是只要有一个表的记录ID就可以关联过去了）
其它信息就不是那么关键，不一一列出了。
纷繁多变的具体业务逻辑和界面，就通过动态加载的dfm+pas来实现。
这样比较彻底的实现了业务数据、业务界面、业务逻辑全部在后台服务器。
3年前基本实现了一套，只是当时限于时间，INI@HTTP使用的不彻底，具体业务的form还是使用C/S直接ado＋数据敏感控件访问数据库的，也还没有采用动态dfm+pas的运行模式。
【
现在我是越来越希望尽量不用第三方控件。。。。。。
原话题（多层架构）里的用到了activex技术（activeform），也是觉得是一个问题
鉴于现在ie下流氓软件的猖獗，我个人是禁用一切activex的，包括flash
一些单位的b/s的oa系统，打印及导出excel等功能，必须使用activex，结果是他们的ie永远无法安全
所以，我是更倾向于使用一个绿色的win32客户端（首次使用可以从网站下载，以后可以从webserver自动检测、更新自己）
与后台的连接就采用http/https协议，后台是一个delphi写的isapi应用，负责真正与后台的数据库打交道
isapi的dll只负责数据的传递到客户端和操作命令（及参数）传递到服务端。。。。。
这样，客户端是win32（或浏览器+js），收到数据后，显示展现有win32或js实现，网络中无须传送与界面有关的html代码，网络里传输的都是最纯粹的数据
更进一步，实现一个基于delphi的win32客户端＋delphi语法脚本的Notes：
http://www.cndev.org/.imgdb/sn10100/GUID-CDCDBE17-AB26-4732-81C1-AF47E54D958E.jpg
（它其实是一个rar包，下载了转存为xxx.rar即可解压，执行里面的testLoadFormApp.exe即可，unit1.pas/dfm和unit2.pas/dfm就是2个实例，
testLoadFormApp.exe就是delphi的win32客户端，它可以加载硬盘里的pas/dfm文件，并把dfm对应的form显示出来，而且实现pas里的事件响应
就好像外部的pas/dfm是预先被编译进exe的一样！唯一的差别是，你修改了硬盘里的pas/dfm文件，让exe重新加载，即可看到你新改的代码的效果！
这才证明外部的pas/dfm不是预先被编译进exe的！）
很欣赏notes的架构：业务数据、业务表单、业务脚本都存储在后台的数据库，使用时加载到前台
只是一直受不了notes客户端的庞大、不稳定，也不喜欢它的basic脚本，所以很想全部使用delphi实现类似的架构
上面的例子就是第一步，把外部的pas/dfm文件改进为从webserver后台动态下载加载，就做到了：业务数据、业务表单、业务脚本都存储在后台，使用时加载到前台！
而设计这些业务表单，编写调试这些业务脚本，都可以通过delphi来进行，只有调试通过了，才把它们的源代码（有必要可以先加密）发布到webserver，供已经在客户电脑安家的exe来取得运行
gif演示动画：
http://www.cndev.org/.imgdb/sn10087/GUID-56451A8B-5DC4-4706-B87D-C89CC1EEE642.jpg
http://www.cndev.org/.imgdb/sn10087/GUID-C6729A9D-3DFA-41D1-9D11-D550F7D5DCAE.jpg
】
介绍见：http://www.ccw.com.cn/htm/center/net/02_4_9_17.asp
运行模式：客户端动态加载服务器上的pas/dfm（文件或流）实现具体的业务操作界面
介绍见：http://liwei.csdn.net/Forum/topic.aspx?topicid=677&total=76&page=4
数据库实现模式：
以抽象的各人的待办事宜为主线，它的每一条记录就是一个工作任务（task,相当于工作模板form的一个实例）
记载了：
本任务的当前办事者（开始可能为空，即多个人都可以办，但是谁也没选中它确定由自己来办）
本任务所属的工作模板（form,一个业务流程里的具体一个步骤界面），它将决定了用户的操作界面和业务逻辑
本任务所对应的具体业务表（table，只是为了冗余。一般form定了，它对应的pas就固定了操作的业务数据表）
本任务所对应的业务记录ID（在具体业务表中，一个业务可能涉及多个表、多条记录，但是只要有一个表的记录ID就可以关联过去了）
其它信息就不是那么关键，不一一列出了。
纷繁多变的具体业务逻辑和界面，就通过动态加载的dfm+pas来实现。
这样比较彻底的实现了业务数据、业务界面、业务逻辑全部在后台服务器。
3年前基本实现了一套，只是当时限于时间，INI@HTTP使用的不彻底，具体业务的form还是使用C/S直接ado＋数据敏感控件访问数据库的，也还没有采用动态dfm+pas的运行模式。
【
现在我是越来越希望尽量不用第三方控件。。。。。。
原话题（多层架构）里的用到了activex技术（activeform），也是觉得是一个问题
鉴于现在ie下流氓软件的猖獗，我个人是禁用一切activex的，包括flash
一些单位的b/s的oa系统，打印及导出excel等功能，必须使用activex，结果是他们的ie永远无法安全
所以，我是更倾向于使用一个绿色的win32客户端（首次使用可以从网站下载，以后可以从webserver自动检测、更新自己）
与后台的连接就采用http/https协议，后台是一个delphi写的isapi应用，负责真正与后台的数据库打交道
isapi的dll只负责数据的传递到客户端和操作命令（及参数）传递到服务端。。。。。
这样，客户端是win32（或浏览器+js），收到数据后，显示展现有win32或js实现，网络中无须传送与界面有关的html代码，网络里传输的都是最纯粹的数据
更进一步，实现一个基于delphi的win32客户端＋delphi语法脚本的Notes：
http://www.cndev.org/.imgdb/sn10100/GUID-CDCDBE17-AB26-4732-81C1-AF47E54D958E.jpg
（它其实是一个rar包，下载了转存为xxx.rar即可解压，执行里面的testLoadFormApp.exe即可，unit1.pas/dfm和unit2.pas/dfm就是2个实例，
testLoadFormApp.exe就是delphi的win32客户端，它可以加载硬盘里的pas/dfm文件，并把dfm对应的form显示出来，而且实现pas里的事件响应
就好像外部的pas/dfm是预先被编译进exe的一样！唯一的差别是，你修改了硬盘里的pas/dfm文件，让exe重新加载，即可看到你新改的代码的效果！
这才证明外部的pas/dfm不是预先被编译进exe的！）
很欣赏notes的架构：业务数据、业务表单、业务脚本都存储在后台的数据库，使用时加载到前台
只是一直受不了notes客户端的庞大、不稳定，也不喜欢它的basic脚本，所以很想全部使用delphi实现类似的架构
上面的例子就是第一步，把外部的pas/dfm文件改进为从webserver后台动态下载加载，就做到了：业务数据、业务表单、业务脚本都存储在后台，使用时加载到前台！
而设计这些业务表单，编写调试这些业务脚本，都可以通过delphi来进行，只有调试通过了，才把它们的源代码（有必要可以先加密）发布到webserver，供已经在客户电脑安家的exe来取得运行
gif演示动画：
http://www.cndev.org/.imgdb/sn10087/GUID-56451A8B-5DC4-4706-B87D-C89CC1EEE642.jpg
http://www.cndev.org/.imgdb/sn10087/GUID-C6729A9D-3DFA-41D1-9D11-D550F7D5DCAE.jpg
】