编写多层COM/DCOM服务程序和客户程序还有必要吗?(100分)

  • 主题发起人 主题发起人 gsand
  • 开始时间 开始时间
G

gsand

Unregistered / Unconfirmed
GUEST, unregistred user!
>Browser负责人机交互,包括一些与数据和应用关系的图形和界面运算;- >WEB server负责对客户端应用程序的集中管理;
>- App Server负责应用逻辑的集中管理(事务处理),Appserver又可以根据其>处理 的具体业务不同而分为多个;
>- DataBase Server负责数据的存储和组织、数据库的分布式管理、数据库的>备份和 同步等等。

我还是有点明白,b/s对客户来说,实际上应该指WEBSERVER/HTTPSERVER和BROWSER,APPLICATIONSERVER实际上支持的是程序员的服务端小程序。

那编写自己的多层COM/DCOM服务程序和客户程序还有必要吗?
况且客户端程序还要编写有一大堆的东西(少者也得用控件)与中间服务程序连接。






 
客户界面通常可以不编,如果界面的功能有限的话,但是如
实现与客户程序同样的功能的话,delphi使用Activeform
这使得浏览器必须权限较低,不很实用。另外如果客户本身
在服务器本网中,具有很高的带宽,则没有必要使用浏览器。
浏览器在许多方面先天不足,这一点,也是曾经有过教训的。
所以浏览器一般适用数据项比较少,功能有限的客户端。
 
而且若都用ASP实现的话
那不是要把源程序都交出去?
被别人随便篡改怎么办?

我的看法是 核心业务还是要作成COM
 
有些复杂的操作Browser和HTML语言没有办法实现。
当然现在这种情况正在改善。
相信以后能做到你希望的:不要客户端,只用浏览器。
但是目前还不行。
 
>而且若都用ASP实现的话
>那不是要把源程序都交出去?
>被别人随便篡改怎么办?
>我的看法是 核心业务还是要作成COM
B/S可以采用JSP/EJB的SERVLET,安全性和性能应该可以满足目前软件要求。
如果是大数据量,且在本网中,应该是双层结构性能较好。本人实在没有实际使用经验,还请各位多多指教。


 
多层编程,我认为有两个方面是不可不提的:1.瘦客户,他可以使得维护变得简单2.在服务方可以使用事务处理.况且多层编程是当今的潮流.
 
我提一下我的看法:
首先,我提醒大家注意xml技术,这是一项新兴起的技术,如果你简单地了解一下
它,你就会发现它使得实际数据和在浏览器中展现的外表能够很好的区分和结合.
其次我觉得,中间的Application server可能会产生一种新型的网站,这种网站
专门负责管理Application server.事实上它的作用和现实生活中的零售商店的
作用和地位类似,我们买东西的时候,很少直接到商品的生产厂家那里去购买,而是
到商店去,尽管商店里比厂家要贵,这是为什么呢?仔细一想我们都能察觉到,商店里
的商品有多种多样,而且对于同一类商品,不只有一家的产品,我们可以选择.事实上
如果Application server能够具有商店的这些性质,那它的作用就不可小视了,
它就会成为信息(IT商品)的集散地,我们寻找信息的时候就不会直接找根源,而去
这些Application server寻找,同样,信息提供着也会把自己的信息送到这些网站
去.
我的一点看法,难免有失偏颇,而且这完全是我自己想的,没有任何的根据,我这样想
的根据就是,计算机技术的发展总是在模拟现实生活.
 
DCOM/COM的技术远远比上Corba成熟。COM+的很多东西还是从Corba杪的(M$的移星大法)
 
多人接受答案了。
 
后退
顶部