W
wu_yanan2003
Unregistered / Unconfirmed
GUEST, unregistred user!
还在MIDAS / DCOM模块上苦苦挣扎的同行们，你们辛苦了，当在大家还在讨论MIDAS技术，还在远程数据模块拖一个个DSP，在客户端拖一个个CDS的时候，我希望你们能好好关注一下这个贴子，关注一下技术本身，深入了解一个三层技术吧。
当然，人都是一步步走过来的，没错，为什么不步子走快点，RAD有没有错？李维的三层架构也没说清楚？这些问题怎么说呢？ 太多的口水，没必要讲别人的不好，技术本身有错吗？2+2+2+2 和4*2到底谁的做法不对？我觉得不是我们应该争论的问题吧。技术本身没有错，它是死的，它是技术。
我们只能说，有更好的方法，更聪明的解决办法。是的，其实MIDAS也挺复杂的，我也不敢说就看懂了。但我们还是了解一下三层基本的技术吧。
看过了socketconn和webService和一些框架之后，我感受蛮深， 三层是什么？三层就是面向对象的设计方法，三层就是多线程，三层就是网络通讯，三层的东西很多。。。。三层架构是一个复杂的东西。我不能，也没这个能力全全俱到的讲清楚。
但我说一下它的核心吧，我把它称为一个远程调用的框架，没错，我就是这么理解的，所谓万变不离其宗，不管是WebServer还是JAVA的EJB，或者XML的RPC之类，它们不都是远程调用吗？说穿了就是： 客户端调用 ->通过静态（动态）代理->序列化->数据打包(加密)->传输->数据解包（解密）->分析数据包->调用服务器端方法->生成数据->序列化->数据打包(加密)->传输->.............
这样一个过程嘛。有人可能说我讲的太抽象了，因为别人不想关心这些事情，希望有现成的东西，那到手里就可以用，我想说，如果你想真正的了解三层，这是不够的。如果你真想学会三层，就把眼阔打开吧。
以下是我总结的一些我觉得有些价值东西，和大家交流交流，希望大家不要扔鸡蛋：
1.客户端不要写SQL语句了。层与层之间可以传输的东西很多，但绝对不是SQL语句。你可以传XML文件，或者数据流，或者对象，都行。但不要再传SQL语句了。
2.不要在客户端去调用事务方法了。这不是你客户端应该关心的问题，事务留给中间层做吧，客户端对象通过中间层的接口，调用业务对象就行了，业务对象根据情况调用事务处理，如有事务异常，应该调用日志类来处理日志，并把错误返回业务对象，再由业务对象返回业务调用成功与否，以及相应信息。
3.数据访问接口（通过该接口访问数据）是需要，但不是主角，如果你的客户端只是用该接口去取数据，再到客户端去遍历，再次获取数据，再运算，然后又生成最后的数据，再次提交，那又回到MIDAS的老路子上去了，就算你数据层封装的再好，全部都是面向对象的，数据对象的传输提交，还不是和MIDAS一样，有什么区别呢？
4.客户端异常处理能力，这一点很重要，发现很多人对这个不太重视，客户端访问数据的时候，处理的异常不能区分是网络故障，还是SQL本身出问题，还是本地网线都已经断开了，还有网络故障这一块，在断线后，基本上大家都是束手无策，要不就置之不理。这样是不行的。更严重的就是程序非法报错。这就更不应该了，至少程序要能保证，在任何异常的情况下，程序都能有正常的反映，而不是报什么异常出错，非法地址访问啦！必须要到任务管理器里面去结束进程啦。。。等等。
5.中间层的业务对象，要划分，不要全部写在一块，最好做成插件式的，每个业务对象里的业务方法是可能会变动的，热插拨支持不了，至少可以重启加载吧！多写几个接口会累吗？可不知给我们的维护带来了多大方便？
6.基本的小工具应该有，可以生成代码，减少我们工作量，数据库这一块，多么复杂，在中间层一个一个语句写，人都快老了，而且数据库在开发阶段，也是经常需要变动的，做一个数据库+元数据的维护工具吧。O/P Maping的简单功能是非常需要的。
7.服务器接口，要按用途划分，而且尽量用基类参数， 传递的时候传递派生类，我定义的接口传递的接口都是基类的，这样接口就不用动，尽量保证接口重用性。当然向上向下转换，类型判断，这些可能会影响点效率，但是值得的。
8.往往三层都不支持负载，容错功能，如果做大型的系统，这是要命的，不可能一个服务器不会出故障。花点时间做一个容错功能的模块，不会太难的。如果有条件，就单单做一个负载处理器（登录服务器），否则也需要在客户端网络故障的时候能使用其它的服务器，
代码嘛，大同小异，都是加载配置文件，一旦一个出错，就调用其它的IP连接，一直到一个可以连接的服务器，否则就提示用户，所有服务器都不可连接，那程序也没办法。
说了这么多废话，大家根耳子都腻了，这也难怪。
就不说了，看看我的三层客户端代码的数据封装层：
遍历数据：
bill := TBillVO.Create;
UILayerWapper.DarwDTOListGrid(bill);
插入：
bill := TBillVO.Create;
bill.PK_Pno := '15';
bill.PK_Mno := '01';
bill.Pname := '新增用电';
UILayerWapper.InsertDTOListGrid( bill);
更新：
bill := TBillVO.Create;
bill.PK_Pno := '15';
bill.PK_Mno := '01';
bill.Pname := '修改用电';
UILayerWapper.UpdateDTOListGrid(bill);
删除：
bill := TBillVO.Create;
bill.PK_Pno := '15';
bill.PK_Mno := '01';
bill.Pname := '删除用电';
UILayerWapper.DeleteDTOListGrid(bill);
批量提交：
//批量提交数据，必须设置OP
bill := TBillVO.Create;
bill.PK_Pno := '15';
bill.PK_Mno := '01';
bill.OP := 'delete';
bill.Pname := '删除用电';
bill2 := TBillVO.Create;
bill2.PK_Pno := '16';
bill2.PK_Mno := '02';
bill2.OP := 'insert';
bill2.Pname := '新增用电';
tmpbillList := TDataTransferObjectList.Create;
tmpbillList.Add(bill);
tmpbillList.Add(bill2);
UILayerWapper.ExecuteDTOListGrid(tmpbillList);
这仅仅是数据层上的封装，十分清爽，也真正做到面向对象，因为我客户端根本就抛弃了数据集，当然也支持它。可能你说这几行代码能看出啥子，那我就告诉你吧，它可以自动绑定控件，绑定GRID，象数据感知控件一样，生成GRID，标题，隐藏字段（这些都可以用工具配置）。而且调用远程数据接口，直接传递对象，然后服务器接收对象，分析，生成对象，取数据，生成SQL语句，调用，再返回客户端信息。
自己感觉这是对学习了一年多时间多层技术的一个简单的总结。希望我的贴子能给大家转变一些固家的观念和思想。
当然，人都是一步步走过来的，没错，为什么不步子走快点，RAD有没有错？李维的三层架构也没说清楚？这些问题怎么说呢？ 太多的口水，没必要讲别人的不好，技术本身有错吗？2+2+2+2 和4*2到底谁的做法不对？我觉得不是我们应该争论的问题吧。技术本身没有错，它是死的，它是技术。
我们只能说，有更好的方法，更聪明的解决办法。是的，其实MIDAS也挺复杂的，我也不敢说就看懂了。但我们还是了解一下三层基本的技术吧。
看过了socketconn和webService和一些框架之后，我感受蛮深， 三层是什么？三层就是面向对象的设计方法，三层就是多线程，三层就是网络通讯，三层的东西很多。。。。三层架构是一个复杂的东西。我不能，也没这个能力全全俱到的讲清楚。
但我说一下它的核心吧，我把它称为一个远程调用的框架，没错，我就是这么理解的，所谓万变不离其宗，不管是WebServer还是JAVA的EJB，或者XML的RPC之类，它们不都是远程调用吗？说穿了就是： 客户端调用 ->通过静态（动态）代理->序列化->数据打包(加密)->传输->数据解包（解密）->分析数据包->调用服务器端方法->生成数据->序列化->数据打包(加密)->传输->.............
这样一个过程嘛。有人可能说我讲的太抽象了，因为别人不想关心这些事情，希望有现成的东西，那到手里就可以用，我想说，如果你想真正的了解三层，这是不够的。如果你真想学会三层，就把眼阔打开吧。
以下是我总结的一些我觉得有些价值东西，和大家交流交流，希望大家不要扔鸡蛋：
1.客户端不要写SQL语句了。层与层之间可以传输的东西很多，但绝对不是SQL语句。你可以传XML文件，或者数据流，或者对象，都行。但不要再传SQL语句了。
2.不要在客户端去调用事务方法了。这不是你客户端应该关心的问题，事务留给中间层做吧，客户端对象通过中间层的接口，调用业务对象就行了，业务对象根据情况调用事务处理，如有事务异常，应该调用日志类来处理日志，并把错误返回业务对象，再由业务对象返回业务调用成功与否，以及相应信息。
3.数据访问接口（通过该接口访问数据）是需要，但不是主角，如果你的客户端只是用该接口去取数据，再到客户端去遍历，再次获取数据，再运算，然后又生成最后的数据，再次提交，那又回到MIDAS的老路子上去了，就算你数据层封装的再好，全部都是面向对象的，数据对象的传输提交，还不是和MIDAS一样，有什么区别呢？
4.客户端异常处理能力，这一点很重要，发现很多人对这个不太重视，客户端访问数据的时候，处理的异常不能区分是网络故障，还是SQL本身出问题，还是本地网线都已经断开了，还有网络故障这一块，在断线后，基本上大家都是束手无策，要不就置之不理。这样是不行的。更严重的就是程序非法报错。这就更不应该了，至少程序要能保证，在任何异常的情况下，程序都能有正常的反映，而不是报什么异常出错，非法地址访问啦！必须要到任务管理器里面去结束进程啦。。。等等。
5.中间层的业务对象，要划分，不要全部写在一块，最好做成插件式的，每个业务对象里的业务方法是可能会变动的，热插拨支持不了，至少可以重启加载吧！多写几个接口会累吗？可不知给我们的维护带来了多大方便？
6.基本的小工具应该有，可以生成代码，减少我们工作量，数据库这一块，多么复杂，在中间层一个一个语句写，人都快老了，而且数据库在开发阶段，也是经常需要变动的，做一个数据库+元数据的维护工具吧。O/P Maping的简单功能是非常需要的。
7.服务器接口，要按用途划分，而且尽量用基类参数， 传递的时候传递派生类，我定义的接口传递的接口都是基类的，这样接口就不用动，尽量保证接口重用性。当然向上向下转换，类型判断，这些可能会影响点效率，但是值得的。
8.往往三层都不支持负载，容错功能，如果做大型的系统，这是要命的，不可能一个服务器不会出故障。花点时间做一个容错功能的模块，不会太难的。如果有条件，就单单做一个负载处理器（登录服务器），否则也需要在客户端网络故障的时候能使用其它的服务器，
代码嘛，大同小异，都是加载配置文件，一旦一个出错，就调用其它的IP连接，一直到一个可以连接的服务器，否则就提示用户，所有服务器都不可连接，那程序也没办法。
说了这么多废话，大家根耳子都腻了，这也难怪。
就不说了，看看我的三层客户端代码的数据封装层：
遍历数据：
bill := TBillVO.Create;
UILayerWapper.DarwDTOListGrid(bill);
插入：
bill := TBillVO.Create;
bill.PK_Pno := '15';
bill.PK_Mno := '01';
bill.Pname := '新增用电';
UILayerWapper.InsertDTOListGrid( bill);
更新：
bill := TBillVO.Create;
bill.PK_Pno := '15';
bill.PK_Mno := '01';
bill.Pname := '修改用电';
UILayerWapper.UpdateDTOListGrid(bill);
删除：
bill := TBillVO.Create;
bill.PK_Pno := '15';
bill.PK_Mno := '01';
bill.Pname := '删除用电';
UILayerWapper.DeleteDTOListGrid(bill);
批量提交：
//批量提交数据，必须设置OP
bill := TBillVO.Create;
bill.PK_Pno := '15';
bill.PK_Mno := '01';
bill.OP := 'delete';
bill.Pname := '删除用电';
bill2 := TBillVO.Create;
bill2.PK_Pno := '16';
bill2.PK_Mno := '02';
bill2.OP := 'insert';
bill2.Pname := '新增用电';
tmpbillList := TDataTransferObjectList.Create;
tmpbillList.Add(bill);
tmpbillList.Add(bill2);
UILayerWapper.ExecuteDTOListGrid(tmpbillList);
这仅仅是数据层上的封装，十分清爽，也真正做到面向对象，因为我客户端根本就抛弃了数据集，当然也支持它。可能你说这几行代码能看出啥子，那我就告诉你吧，它可以自动绑定控件，绑定GRID，象数据感知控件一样，生成GRID，标题，隐藏字段（这些都可以用工具配置）。而且调用远程数据接口，直接传递对象，然后服务器接收对象，分析，生成对象，取数据，生成SQL语句，调用，再返回客户端信息。
自己感觉这是对学习了一年多时间多层技术的一个简单的总结。希望我的贴子能给大家转变一些固家的观念和思想。
]