delphi的三层是由服务端和客户端组成,以socket为话题
    但是在用户很多,界面有130个,并发性强的环境下,假设500用户为例,且数据库的数据量很大,上千万的数据,因为不是简单的select语句,很多逻辑都是封装写在存储过程里面,事务也多,数据库锁死的情况也不少
如果只有一个中间层,有时也会出现中间层卡死的情况,我的想法是建立多个中间层服务器,如A,B,C,D,E
    用户依次向服务器请求发送连接信号,返回服务器的连接用户数,如果A服务器连接用户数达到100,那么尝试连接B,如果B连接也达到100,那么连接C,依次类推,这样是否可以就达到负载平衡的目的
但是这样的话,如果我要升级服务端,那么5个服务器的中间层我不是都要更新才行,我觉得还是有点麻烦
   我的数据查询连接方式为DbExpress,数据更新方式为ADO,服务器端配有2个数据库链接,我个人觉得这样好点,查的快,更新也稳定
   再来说客户端更新的问题,增加和减少客户端DBGrid里显示的数据字段客户端当然不用升级,服务端操作下就可以了,我的想法是在客户端建立一控制服务端dateserprovider字段的功能,这样在客户端就可以做到类似这样的维护目的
   但如果是客户端增加界面的问题,或者要加入系统卡点,防呆的时候,就不得不更新客户端了,目前我没有找到彻底解决升级的问题,各位有什么好的想法,希望大家讨论讨论
   我的客户端菜单是动态从数据库加载的,有MainMenu和TreeView结构,事件响应部分也是自定义函数实现的(按钮单击打开什么窗体也是由数据库加载的,可以自定义改变,方便维护),所有元器件基本都是即使创建和释放的,界面控件很少
   图片,ICO部分是从RES资源文件动态加载的,这样可以减小客户端的大小,窗体类是编写在dll中,用到时调用希望有更好想法的朋友可以提出点建设性建议和一些架构三层的方式,大家一起讨论讨论    
    
     

解决方案 »

  1.   

    我是倾向于不要自己开发socket服务端,直接借助于IIS这样的webserver,它们的高效、稳定是久经考验的
    数据库是一个,webserver、应用服务程序可以分步在n多台服务器,
    但是每个服务端还都是访问入口(负载均衡信息的收集者),
    入口负责返回一个它所知的最闲的服务器给客户端,客户端再去使用那个服务器
      

  2.   

    是這樣的,項目是ERP,用WEB的話刷屏太厲害,用戶無法接受的
    所以才用Delphi7自己做三層的,減少服務器的連接數,複雜邏輯我都寫到SP里好了
    最近看那個CBX感覺不錯啊,EXE跑到流覽器裏面了
      

  3.   

    客户端嵌入ie,是容易对付那些只懂得赶时髦(ie就行)的用户
    不过,activeform做稳定、易用(比如tab/回车/箭头键的控制)也需要一些经验
      

  4.   

    bs的话, 还是用.net或是javadelphi CS,也可以用bpl
      

  5.   

    我改寫了下,原來圖片編譯為dll效果更好,不會增加程序的大小,只要發佈一次就可以了,不加在程序裏面,升級的時候會快一些
      

  6.   

    我的经验,开发自己的socket服务器和客户端。
    1、服务器的动态ADO连接,组件尽可能少一些,占用内存更少。一个ADO可以重复访问多个数据库文件。
    2、服务也使用静态ADO连接,编成相应的函数,由客户端直接远程调用。
    3、大量的计算放在客户端,让服务器仅存取数据。
    4、可以考虑,将一些非公共数据,存放在客户端,减少对服务器的访问量。
    ......
      

  7.   

    我的客户端菜单是动态从数据库加载的,有MainMenu和TreeView结构, 可以保存在本地数据文件中,与10楼的想法有些相似可以考虑,将一些非公共数据,存放在客户端,减少对服务器的访问量。
      

  8.   

    还用delphi 7开发新项目,不是吧?以前开发的,哪是不得已的,新项目,应当用新的datasnap(delphi 2010 delphi XE)了吧!中间层确实不应当放大多的东西,现在的客户机都很强了!关于三层的,欢迎加QQ群交流:41464226
      

  9.   

    我接觸到的軟件公司很少用Delphi了,都要轉.net,哎
      

  10.   

    delphi的三层多数都只是非常简单的把数据库访问独立出一层而已,并非真正的意义的中间件服务器。
    当然这样也有几个好处:数据库库访问安全性,限制数据库连接数(*)
    若仅仅从限制数据库连接数的考虑做所谓的三层,在windows平台下的数据库服务器,比如sql server,连接基本不占服务器资源,只需要几KB的内存而已。真正耗费资源的是应用本身的sql访问,而这一点跟连接数关系
    不大,而只是跟实际的应用强度有关。
    根据我的经验,往往这个所谓“三层”架构只能增加耗费(中间层到客户端的传输(如果是走http还更慢)),降低速度,基本上客户端直连数据库的速度比“三层”快一倍以上。多层架构的中间层设计,考虑的方向应该调整为:对业务逻辑处理处理(利用硬件和网络资源优势做复杂计算/)、多类型客户端(web,win32,多平台)访问、安全性、7*24稳定性等等。而非资料库连接,要考虑,也要针对当然不同的数据库不同的操作系统平台,连接实现的原理和对资料库的影响是不同而做考量,而非简单的一个delphi三层架构,再加一个负载平衡就可以做到通用。
    简单的是最快的,任何的三层都没有比直连DB快,而且,每加一个处理概念或逻辑,带来的复杂度和不确定性都市需要考虑的。比如负载平衡真的就能很有效率吗,他本身也会带来一些需要处理的东西。
    所以实际上成熟的成熟的中间件一般都是大公司在做,比如websphere,iis,weblogic,因为这个涉及的技术太广太深,普通的应用开发,我觉得建议直接采购这些产品,要么就使用简单有效成熟的技术来处理。
      

  11.   

    同意!很多人在Dephi下用三层只是形式上的三层罢了!
      

  12.   

    Delphi自动生成的scokte服务器,确实是如同16楼所述,但你可以增加功能的。这样,逐步成为一个真正意义上的服务器。 
      

  13.   

    其實D本身在socket 上面只是提供給我們一個基礎,想做好,技術夠牛的話也是可以完善的,難度是不小,
    也很難找到相關的文章,真正有價值的東西部容易見到
    感覺玩com的比較多
    目前不是有個CBX框架么,沒接觸過,感覺還不錯,可以去研究一下
      

  14.   

    可以参考一下:
    三层架构delphi+Java+Oracle模式的实现http://blog.csdn.net/lxchenjun/archive/2009/01/04/3705375.aspx
      

  15.   

    我是这样做的
    delphi7+indy+json+tomcat+servlet+mybatis+sqlserver使用JSON作为中间数据格式传递。
    客户端用delphi+indy9处理http收发json数据
    服务器端用tomcat 作为服务器
    用servlet来做为服务端并实现业务
    mybatis实现数据实体化。
    事务在sqlserver存储过程里实现。看上去很复杂,但是每个都是发挥各自的优势,并且降低媾和度,每一块都可以单独开发。
      

  16.   

    新读了本书,介绍Delphi+MSSQL+ASP.Net特点不限制访问量(客户数),可使用浏览器访问。
      

  17.   

    23楼的那种架构的方式应该是这样的么
    Delphi做中间层,业务逻辑的处理,处理数据的操作,因为D在数据库上的效率还是不错的啊,ASP.NET开发客户端,可以浏览器访问