通过MIDAS,你可以把CLIENT/SERVER应用分发到层,每一层实现一种逻辑上独立的功能。多层应用的优点就是你可以很方便的替换应用中的每一层,因为每一层都不知道其他层是如何实现它们的功能的。并且,每一层通过特殊的方式和其他层通讯,并只对其他层提供的服务感兴趣,而不是如何提供这种服务。最简单的分布式应用是三层式应用。在三层式应用中,客户端的角色就是显示数据。中间层处理所有的交易逻辑,第三层是数据库服务器。
解决方案 »
- 读取其他进程启动参数?
- 如何自动生成编号??不重复的。删除就可能会出现重复。请问如何解决
- 小小生日快乐
- 按理说不会出现这样的情况,但我还是碰到了.
- 我为程序中的职工设了一个序号,人数有多少序号就有多少。可以一眼就看出有多少人。可是当我在离职表中删除职工时。序号跟着被删除。删除
- 怎样去判断一个字符串里是不是有某个字符!
- 请教怎么把查询出来的数据另存为其他文件
- 如何给sql server数据库中image类型的字段赋值?
- 如何将quickreport设置成横排打印?(在线等待)
- 如何解除delphi5 trial的时间限制?
- 红旗linux-------千万不要说此贴与delphi无关!
- InsideDelphi(ID) 非常感谢你。请来拿分
airhorse,继续呀!
b/s-----browser/server,浏览器/服务器结构,可以将它看成是c/s的一种特殊结构。(先这些)
一个常见的b/s实例是browser(ie)+iis+asp(active server page)页面+ms sql server.事实上,这时候的客户端应用程序是ie,你的好处是不必在编写客户端的一句代码,不是吗?(除非你想自己做一个浏览器),microsoft已经给你做好了一切。看上去,你像在做一个零客户/服务器系统。所有的asp页面被放在web服务器上,由iis解释执行,向后端sql server取数据,然后再返回这些数据给前端的浏览器。如果“偏激”一点讲,将这些asp程序当作“客户”,然后asp程序调用ado或者用户自己编写的组件来对后端数据库进行操作,也可以。但基本上,我们要做的是升级iis版本,或者ado,或者你的组件,或者修改asp页面来提供internet/intranet服务.这是b/s的好处,易维护,操作简单(对最终用户而言),但是b/s结构存在安全性、实时性差,很难实现复杂的分布式计算。对于提供信息服务,b/s结构是非常好的。
1、有利于升级和维护
当client非常多时,3-tier/n-tier的这个优势将明显的表规出来。如果有新的需求,开发人员可以只更新中间件部分。
2、可以限定用户的情况下,增加用户访问数。
可以利用pooling技术(资源共享)实现这一点。
1.2.1 两层体系结构模型
两层结构按功能可以分为客户层和服务层,如下图1.2.1所示:
图1.2.1
客户层包括应用程序和一个或多个JDBC驱动程序,其中应用程序完成下列功能:
 表达逻辑
 商业逻辑
 多状态或分布式事务的管理
 数据源管理
在这种结构中,应用程序直接和JDBC驱动程序交互,包括建立和管理物理连接以及处理特定数据源实现的细节。应用程序可以使用特殊的机能,使用非标准特性对性能进行协调。
这种结构的有以下缺点:
 其下层结构和系统级功能的混合式表达及商业逻辑,对一个明确定义的体系结构编写可维护的代码有一定困难。
 由于编写的代码和特殊的数据库操作,致使其代码缺少灵活性,如果和多个数据库操作,应用程序必须清楚的知道各个数据库。
 由于应用程序一直和一个或多个数据库连接直到它终止运行,所以限制了并发执行。在这种结构中,JDBC驱动程序和相应的数据源管理着执行的结果,升级性以及有效性,如果一个应用程序和多个驱动连接,它必须知道什么时候某个数据和某个驱动连接。
1.2.2 三层体系结构模型
三层结构是增加一个中间层来封装商业逻辑和下层结构,如下页图1.2.2:
这种结构可以提高企业级应用程序的执行性,可升级性以及有效性。从功能上看可以如下分各个层次:
1.客户层——一个薄层,执行和用户的交互。Java程序和Web浏览器都是典型的客户层执行工具。客户层和中间层交互,但不需要包括任何低层数据源的功能。
2.中间层服务——中间层通常包括:
 和客户层交互并且执行商业逻辑的应用程序。如果这个应用程序包括和数据源的交互,他将要执行更高级的抽象,如相对于低级的API,它会执行DataSource对象和逻辑连接。
 一个应用程序的服务器,它提供支持底层结构的某个大范围的应用程序,它还可以包括管理,物理连接池,事务处理管理以及屏蔽不同的JDBC驱动之间的差异,后边这一条可以使我们可以编写更加灵活的应用程序。该角色可以由J2EE服务器来实现,应用程序服务器执行更高级的被应用程序和JDBC驱动径直交互的抽象。
图1.2.2
 JDBC驱动提供和底层数据源的连接,无论支持底层的数据源是何特征,每个JDBC驱动都执行基本的JDBC API。驱动层可以屏蔽基本的SQL99语法和本地数据源支持的语法之间的差异。
3.底层数据源——数据存放的层。它包括相应的DBMSs, 传统的文件系统,面向对象的DBMSs, 数据库,电子数据表或者别的表达数据的方式。唯一的要求是相应的驱动要支持JDBC API.
从站在客户的角度来说,主要是
1.整个处理安全性大大增加,因为同后台数据库的操作基本上放在中间程,即应用服务器上。
2.系统以后的升级极其容易,如客户想将其转变为intranet下或internet下B/S架构下系统,
基本上只需修改前面显示的代码即可。
中间件(如MTS, TUXEDO等)通常还担负了事务协调器的角色
即Transaction Coordinator或Transaction Monitor
可以处理全局事务,即需要多个资源管理器(数据库,消息队列等)
参与的事务,事务协调器可以保证他们的一致性
1.速度慢.
2.开发成本高.
3.应用服务器昂贵,并且,相对于大多数小型应用来说,根本没有这个投入的必要.(你试试,让那些windows都用盗版的用户买个AS看看)IT界的技术总是风起云涌,目接不暇的,我们往往不去进行具体的分析,就匆忙上马,完全不理会普通客户和普通程序员受得了受不了. 并且总要迫不及待的宣称:我们用的是最~~先进,最~~潮流的东西,言下之意就是:我们要多收费,乱收费哦~ 当然,我不是要否认多层结构的理论优势,我只是想说,我们要做适合国情的东西,踏踏实实的来.
为什么要采用组件化设计
传统应用程序和组件化程序的比较
优点:
2. 更新容易,组件可在运行时替换
因为组件应用程序是在运行时动态连接的,所以只要接口不变,新版本的组件可任意替换老版本的组件。
3. 可定制的应用
可根据用户的不同喜好动态定制。
3.协作开发
由于COM组件的语言无关性,可采用几种开发语言协作开发。
4. 节约成本,可重用
可建立自己的组件库,在开发时直接提取使用,大大加快开发进度。
5. 使复杂问题简单化
可将大型复杂的系统,分解成较小的模块,降低了系统设计和开发的复杂性。
6. 合理利用资源
1)、从分布式组件的部署上考虑,提高系统性能
2)、从设计角度考虑,使具有不同特长的开发人员都能发挥自己的专长,人员可以灵活配置,不同的阶段使用不同人员。
7. 容易管理
一个好的设计它的进度应该是可控,可预见的。同时它应该有良好的附加文档。
8. 易与维护
这是COM组件的封装性带来的好处。
9. 设计更完美
能充分利用面向对象的设计方法,设计的组件更具人性化。
缺点:
1. 版本比较难于控制
2. 对接口的设计要求很高
3. 团队协做要求更高
特别是com+,强调的是无状态的组件设计,是过程化的对象