B/S和C/S的架构就要要淘汰了吗?!不同于这两种构架的新技术探讨。 ( 积分: 200 )

  • 主题发起人 主题发起人 差不多算了
  • 开始时间 开始时间
delphi+asp.net做的b/s ,delphi用来采集数据 asp.net现实数据
 
B/S与C/S看你用在什么地方,关键是看项目需求,万物存在就是其道理,相生相克,相辅相存!
 
其实无论:Delphi + Asp.net,还是Delphi+java等结构,都同样存在很多问题
1、客户端是独立程序,这样就存在发布的问题,灵活性不如b/s的好。
2、更新下载内容量大,如果都做成动态链接库之类的还好点,不过,开发调试相对复杂。
3、经过实际的应用,这类结构在普通的Adsl网络中,速度不是很好(同网的还可以,比纯B/S的速度好些)。
...
 
楼主在“造概念”,这种做法不好。
我觉得RemObjects比楼主的要好的多。
 
造概念?你看到我的东西了???
这个概念和RemObject有什么关系?
呵呵,别理解错了,我不是在说dbanywhere
,dbanywhere这个东西就是delphi+java做的C/S+B/S,
目前说的不是它,别理解错,兄弟。
 
而且:
RemObject,DbAnyWhere能够实现这个要求吗?
1、程序界面文件和脚本文件(程序逻辑)保存在服务器端
2、客户端属于虚拟机类型(也可以叫解释器),可以自动获取服务器端界面和脚本定义并解释执行
3、客户端是应用程序样式界面
。。。。
 
界面的处理及控制是很简单的,同B/S,C/S没有一点联系。楼主了解了MVC就知道是怎么一回事了。
处理比较难的是OR MAP,这方面RemObjects的DataAbstract做的相当好。
 
MVC了解的太多了,我们开发组就有自己开发的Java的MVC平台 jideation ,
问题不在这里。
 
差不多算了,是位分布式的专家。景仰。
 
把元数据放在数据库,运行时根据元数据创建界面。目前金蝶的k3、用友的u8很大一部分功能是这样实现的
 
界面的存储和显示方法有多种,可以类似 Asp,Php,jsp等以文件的方式存储,也可以存储到数据库,这些都可以。我感觉更重要的是业务逻辑的处理,界面和逻辑完美的集成效果,达到和C/S那么灵活应该很重要。程序逻辑的处理粒度应该控制到什么地步,这个比较关键。
目前很多平台做的业务流主要是针对OA很方便,因为应用系统就象游戏一样,有 RGP游戏,有即时战略游戏,分别不同。
 
继续讨论...........顶
 
感觉味道怪怪的。
 
我觉得做程序的不要什么规限于什么什么结构,具体情况具体订。
我们公司现在的大型程序就是用所谓的B/S + C/S 还有很多技术混和的。
无非都是为了
1.开发周期
2.程序性能,负荷
3.向下向上兼容,后期管理问题
 
因为目前就b/s和c/s的结构,应该有更好的结构,
有了好的结构不用这么复杂的东拼西凑了。
我认为好的框架结构很重要。
 
我相信解释型的语言应该是以后的发展方向,因为这样可以更容易的进行修改应用,发布更容易(比如b/s的东西),但目前的b/s系统的客户端实在有不是很灵活,要灵活的点的话还比较复杂,和c/s的灵活性差别太大,这也是c/s一直有很多的产品做的非常好.
这么多年了,一直很多人在讨论,到底是c/s好还是b/s好,叫我说的话,我感觉都好,也都不好,各有优缺点啊,这里不讨论到底哪个好,我认为应该要做出结合c/s和b/s的架构出来才是最好的办法,当然,这不是简单的将c/s和b/s结合起来就可以的(目前确实很多公司这么做,比如服务器是.net或者java等,终端采用delphi或者VB等).
所以,好的结构应该是符合以下几个特点的:
1:程序逻辑文件部署在服务器端,而不是象c/s一样每个客户端都拷贝一份.
2:终端应该是浏览器类型的,可以象IE一样直接从服务器获取程序逻辑,界面文件等,并自动执行,而且要有和c/s一样的灵活性,决不是象b/s那么笨拙(又是js,又是ajax等等).
3:执行环境可以在单机/局域网/广域网等环境下执行.

我感觉,这样的结构才是符合目前的企业的真正的需要的,既可以实现企业复杂的操作要求,有可以满足企业网络环境的各种要求.
 
软件是为现实生产和生活服务的,随着时代的发展而不断发展。
 
使用XUL可以解决楼主的所有问题
 
Xul其实还是b/s的东西,内置了自己的界面描述和解释,确实这点很不错了,我也发现有些公司在用,不过,不可能解决我说的所有问题,界面灵活性是可以的(具体灵活到什么地步,能不能和delphi差不多,我没用过不太清楚,估计不行),但还是b/s的东西,无法实现离线运行啊。
 
后退
顶部