我们公司想开发一个三层的软件,但又不想直接操作数据库,想用一个中间层进行操作,不知哪位有过这方面的经验,难否给个思路

解决方案 »

  1.   

    我的做法是做一个服务器,与数据库连接,客户端通过socket与服务器连接,然后服务器从数据库存取数据。为了解决多个客户端同时连接的问题,对连接请求进行队列处理。代码恐怕比zhykhld(独木桥) 的还多,但目前可以在城域网内使用。
      

  2.   

    第一层:数据服务层,多用存储过程
    第二层:中间服务间,需要你写大量通用的DLL文件,所有的库操作都写在这里
    第三层:客户端,需要的就是界面部分,和向中间层传递参数了
    这样的话,以后维护安全都很方便
    但是前期有设计工作太多了
    你要对功能模块进行细分,才能知道中间层上要写多少个文件才可以
    而且中间层的文件大部分是通用的,所以小心小心
      

  3.   

    "标准" 三层的做法教科书上或者网络上有例子,数据库中的一个表对应代码中的一个实体类和集合类。在类里操作数据库,客户端使用类提供的方法。
    本人很讨厌这种做法,效率低不说,还把程序搞成四不像,我觉得VB的优点是开发效率而不是面向对象,没必要做这种卖力不讨好的事情。本人现在就在维护这样一个系统,先前设计系统的人祖宗十八代都被我骂过了。把具体的业务方法做到中间层里去,在中间层里直接跟数据库交互,但是中间层跟客户端交互主要通过值类型数据而非对象,例如串行化的记录集等等,效率高而且代码量很小,易于扩充。如果是在局域网环境中,客户机跟中间层的通讯可以用COM+。广域网的话可以用Socket或者WebService。
      

  4.   

    VB在面向对象方面确实不强,但并不能说VB在面向对象上就一无是处,多层结构的代码是否容易维护不在于是否是使用VB编写的,决定的主要因素是代码的编写质量和维护人的水平楼上说:
    本人现在就在维护这样一个系统,先前设计系统的人祖宗十八代都被我骂过了。这只能有两种原因,一是先前设计系统的人代码写得很烂,二是你的维护水平可能还差了一些一个结构不佳的代码,就算是用VC或者Java或者其它的什么语言写的,一样难于维护
    VB本身就是一个用对象组成的系统,你不也说它使用起来很方便吗?
      

  5.   

    楼上的人思想容易走极端。我的意思是针对VB里的多层结构,而不是VB的面向对象机制。也许其他面向对象开发工具里开发多层是用这种办法,但我想这肯定依赖于开发工具本身的一些特性,好像在Java里就有现成的框架可以动态的把结果集转换成对象的。不过在VB里你做不了这种动态,只有Hard Code,数据库结构稍微修改一下就得到处去改代码,这点我深有体会。也许有人会想到可以把对象的属性放到集合里,这样就可以动态的跟结果集建立关系。这样做也行,我曾经也尝试过,不过等你都做好的时候你就会发现它跟ADO里的记录集结构已经差不多了。我所理解的多层重点是是分离业务,而不是非得要把表映射到对象上才有意义。本人不懂Java,上面说的关于Java的也是道听途说来的,大家不要见笑。
      

  6.   

    哪用Socket还是WebService好呢。
      

  7.   

    用WebService简单、方便而且高效。而Socket控制起来比较复杂。
      

  8.   

    用WebService简单、方便而且高效。而Socket控制起来比较复杂。
    同意。
      

  9.   

    呵呵,谢谢fj182(阿花)高水平的口水,本人真的很想和别人探讨一下这方面的问题首先我要声明,我并没有说VB的程序应该就是三层的,我也没有说每一层要干什么,分不分层完全取决于软件本身,该分就得分,不分则乱,不该分就不能分,分开则散.非要说用VB编程无需分层也是极端.本人才疏学浅,不知道什么样的东西叫做动态框架,数据结构哪怕是小小的改动,代码也必须要修改,这当然也是对的我的做法可能你想不到,我没有把数据记录集的结构重新做了一遍,那样没有意义,数据库结构如果只是小小的改动,在我这里修改起来就很容易的,原因就在于好的代码结构多层的目的当然是要分离业务,这样才能让程序更合理,但我确实把表映射到了对象上了,目的是为了让程序能最大程度的减少逻辑上的错误(因为SQL语句就是字符串,如果把表结构映射到对象上,可以把一部分逻辑错误变成编译错误),对于查询记录集,我把它向上交给界面层了,这似乎不可理解,但对于VB来说就是应该的,只要表结构成为了对象,就不会有太大的问题用VB编程,不论是什么编程方法,都不应该让代码更难用,我的原则是:最简单的就是最正确的.但这里有个度,不能一味追求简单与容易,更重要的是代码的质量,如果你的编程方法使你代码的质量下降了,那么不论分成了几层(包括不分层),你的代码结构也一定是不合理的.好的代码应该在易用性和质量上都合格.本人的代码分层次以后,任何层的逻辑结构和使用方法都变得非常简单本人如下理解"层"的概念:
        逻辑处理层:重要的代码层,公布对数据库的各种操作,公布数据库的结构,公布数据的属性,对功能层层细分,如果有好事者,可以把它再分成若干层,呵呵,但是就没有意义了
        界面处理层:重要的代码层,直接面向用户,使用逻辑处理层的功能去操作数据库
        数据库结构表示层:非代码层,说白了就是一个数据库分层的原因,本人是这么理解的:
        1.要求共用代码
        2.尽量减少错误
        3.功能太多,需要明确的分开
        4.逻辑复杂我想,fj182(阿花)应该明白了,本人的想法并不是总和你相左的,只是对分层的看法不同罢了本人的编程方法和代码结构并不是从哪本书中得来的,灵感来源于VB6的ListView和VB.Net,经过了多个项目和时间的检验,但仍然不太成熟,纯属于闭门造车,哪里有不对的地方,还希望各位多多指正,本人不胜感激最后说一句,不论是分几层,代码的编写难度都会加大,但这是源于VB程序员对层次式编程的不了解(不过代码行数增加的特别多,这就没有办法了)
      

  10.   

    呵呵,谢谢zhykhld(独木桥) 高见。
    我觉得做多层分布式应用时还是面向服务的思想比较好,服务端(业务层+数据持久层)提供服务,客户端来访问服务来完成某个业务。但服务端不为客户机维持状态,对客户机而言访问服务也就成了原子操作(这样做的好处事务控制简单)。
    以前设计过一个系统用了这样的结构,感觉还不错。                Client                                   Server
    客户机<->服务访问代理(客户端组件)<-> Soap <-> 服务访问代理(服务端组件)<->业务层(COM+组件)其中加入服务访问代理的目的是为了简化系统,客户端部分用来封装请求,而服务器部分用来解析请求并统一控制事务,(要是做WebService的话,最大的好处是在服务器端只需要一个WSDL文件就可以了)。