大家来讨论，关于三层的接口设计和数据传输

Question

客户端和数据库就不用说啦。我将中间层又分为三层：
第一层面向客户端，根据需求分为三个接口
    Iagent:座席
    Imonitor:班长
    Iadmin:管理员
    班长接口继承自座席，管理员接口继承自班长（类也如此继承，需求如此）
第二层是业务逻辑层，按模块划分了几个相对独立的接口，暂时有六个，以后肯定还会增加。
第三层面向数据库，为了统一数据库的存取，所有业务逻辑层的接口要访问数据库都要通过这层。定义了几个函数
要讨论的是：
1.这样做是否合理？
2.各位在做实际应用时，是给客户端一个接口还是给一批接口。其实我的第一层只是将业务逻辑层包了一下，暂时出于权限的考虑。
3.各位在传输数据时是用什么方法做的，不知MIDAS怎么用在ASP中？开始我想直接用_RecordSet传数据，可是客户端提交数据怎么传给服务器呢？OleVariant数组可以做到，可是那样要定死顺序，想活一些。
4.COM的组装性体现在哪里？Delphi不支持多继承，如果我想加一个模块，要在面向接口层的接口内声明所有新模块的函数，还要实现，有什么好办法简化一下。
4.做过实际应用的兄弟有什么经验教训，不妨说说，以免大家走弯路。另外，李维说事务很费资源，要我们尽量把对数据库修改的函数写在一个组件内，然后需要事务；对数据库读的函数写在一个组件内，然后支持事务，可是我要是这样做，业务逻辑层的组件要增加一倍啊，各位有这样做的吗？

Answer 1

1、设计合理，其中1在客户端，2，3在服务段。
2、肯定是一批了，一个那够。
3、用TClientDataset提交和获取数据呀。
看《Delphi5.x分布式多层应用系统篇》吧
http://www.codestudy.net/ 上面的书都是最新的，还有(Delphi7.0de)
http://www.mycnknow.com/srindex.htm
http://kingron.myetang.com/
4、不用多继承，而用接口其实是很好的办法，
用通俗一点的说法就是“不要到处拜老爸“，现在构件技术中强调的是
先建构架（建立继承关系），在构件复用（一般是对象组合，通常用接口来实现）
接口是对象之间的通信协议，可以达到良好的设计，建议采用。用DCOMConnection吧。

Answer 2

谢谢楼上的兄弟。
2.暴露给客户端N个接口？我想用一个接口包起来，比如客户端没有看报表的权限，我就不把报表接口包进去，客户端用一个接口，不知这样有什么缺点？
3.请问一下在ASP中如何用TClientDataset呢？有没有个简单的例子。

Answer 3

“客户端用一个接口”
那么在这个接口中包含的多个接口的创建方式就会有两种：
1、在客户接口创建时创建所有内部接口；2、在客户接口调用相关功能（如报表）的接口时创建内部接口（报表接口），然后执行相关操作。
第一种方式要考虑在创建客户接口时较慢和服务器资源的占用（因为所有内部接口都创建了）；第二种方式要考虑客户调用相关功能时较慢。
我的做法是将不同模块做为不同的接口暴露给客户端。“开始我想直接用_RecordSet传数据，可是客户端提交数据怎么传给服务器呢？”
我没有看到有_Recordset类型的参数，你是想把ADO的查询结果_Recordset做为Variant类型的参数输出，在ASP中再用ADORecordSet打开吧。这种方式我没有试过（我在做C/S的程序）。

Answer 4

谢谢WangPeter(Peter)兄的参与，你好像误会了我的1的意思，我想在客户端只创建一个接口，这个接口中包含了第二层（即业务逻辑层）的所有接口的函数。比如：
Iagent下有
  procedure aaa;
  procedure bbb;第二层中有两个接口Iaaa和Ibbb,分别有Iaaa.aaa和Ibbb.bbb。
procedure Iagent.aaa
begin
  Iaaa.aaa;
end;
procedure Iagent.bbb
begin
  Ibbb.bbb;
end;
只是简单包装第二层的函数。至于在ASP中再用ADORecordSet打开_RecordSet，没问题，我试过，只是提交时不知怎么办。

Answer 5

学习中，希望有更多高手来讨论—————————————————————————————————
┏━★━━◆━━★━┓ 
♂欢|◢ＣＳＤＮ◣|使♂ 　　　　　　　▲自由保存帖子，浏览，关注检测
┃迎|◥论坛助手◤|用┃ 　　　　　　　▲完善的ＣＳＤＮ客户端工具
┗━☆━━◇━━━☆┛　　　　　　　▲自动添加签名......让你更快，更爽，更方便地上CSDN...
http://www.csdn.net/expert/topic/573/573604.xml
http://www.chinaok.net/csdn/csdn.zip

Answer 6

我觉的客户端用一个接口并不是一种最好的方式，一个很简单的例子，基于组件的编程就是希望能能有很大的灵活度，想一想，如果服务器需要升级的话，那么客户就有可能要放下手头的一切工作，而且，一量这个组件崩Kui的话，谁也不知道会发生什么后果，然而，客户端用不同的接口可以Pi mian这种情况；这仅仅是一个方面，当然业务层需要处理大量的数据时，你会不会只给客户端提供这一个接口让其调用所有接口方法？这应该是分布式编程的一个ji Hui，是否想到，当有特殊要求时，一个接口根 本就无法满足的； 还有，比如你的业务逻辑层有一些或者是很多的接口，那么你用什么方法或是最好的方法将这些接口都统一的让一个接口来管理？会不会如：WangPeter(Peter) 兄所言？ 
  “客户端用一个接口”
那么在这个接口中包含的多个接口的创建方式就会有两种：
1、在客户接口创建时创建所有内部接口；2、在客户接口调用相关功能（如报表）的接口时创建内部接口（报表接口），然后执行相关操作。
第一种方式要考虑在创建客户接口时较慢和服务器资源的占用（因为所有内部接口都创建了）；第二种方式要考虑客户调用相关功能时较慢。
 
再者，我驿接口的继承也不是很赞同，也不知道你在这一点是如何做的，当一个工程变的很复杂的时候，每一个改动都会影响到整个组件，问：你是如何做到的组件无关性？模块分离性？用继承吗？
那么你的面向对像性提体在那儿？组件的特性又会提体在那儿？
传递数据的方法，Midas的传递方式或许让我们无法再做选择，那么此时，可能就要在传输过程中进处理； COM组件的特性提会在那儿？这个问题，如何说呢？呵呵，这要看你对COM的应用如何，不过，我知道青苹果对COM也是有研究的，在这儿也就不好意思在 指手画脚的误导别人了：)头有些婚，先休息一下

Answer 7

我倒是觉得苹果兄的关于提供一个接口的想法应该可以.客户端只是向该接口要求功能比如:appserver.入库单审核
 
至于其余的全部可以由代理对象,也就是第一层进行组织.比如可能要调用:
入库单对象.修改审核标志,库存对象.增加库存等等.
而如果将来的审核流程改变的话,我们只需要给改变代理对象的一些业务逻辑.
而不需要修改客户端的任何东西.不知道有什么不妥.以上只是我个人结合书上,以及别人论点的一点想法,不知道对不对,清各为指正.可是因为我用的是oracle,在事务的控制上出了点问题,不知道有没有人碰到过cannot connect to the trasaction manager or the transaction manager is unavailable
的问题?

Answer 8

oracle没用过，帮不上忙了。
摩托，你的烤肉还没吃完么？
大家继续讨论，苹果去看看事务：）

Answer 9

NO.1:
Proxy/Stub;
NO.2:
一切都用IAppServer有些勉强:)
NO.3:
MarshallIng;

Answer 10

大家可以学习一下Facade模式，就知道怎样组织接口了。
BTW，多看点OO分析和设计的资料没什么坏处。
祝大家新年快乐！！！

Answer 11

用asta啦，3。0有源码，for oracle 的也有，我试了，不错，功能强大，还有，三层开发，我认为dcom只能用在局域网，而socket就没有这个限制，因为在internet上用dcom，太危险，不安全。
 欢迎一起探讨

Answer 12

呵呵，这两天正在统一规划。
那个asta是什么？楼上的兄弟给讲讲。

Answer 13

asta是一个第三方的三层程序开发工具，很难找到源码

Answer 14

苹果兄是否未采用midas，而是自己封装对象？

Answer 15

嘻嘻，我是懒人，都用midas了，如果苹果兄要自己封装对象的话，可参考一下EJB的一些规则，数据库中依附于其它表而存在的表就不用封装成对象了，可做成辅助类的形式，随所依附的对象传递到客户端.

Answer 16

牛ren真多，学习中...
//************************
//*天行健，男人以自强不息*
//************************