RIA 体系中的设计模式- RIA 设计(翻译)
2004-06-10 10:36
357 查看
声 明
本章节由网友 azure 翻译,由笔者负责后期的文章润饰。
--------------------------------------------------------------------
RIA设计
现在企业应用程序一般是分层进行设计,也是根据这个组织程序逻辑的。下面就是典型的N层的应用程序模型:
![](http://blog.csdn.net/Develop/ArticleImages/28/28909/CSDN_Dev_Image_2004-6-92142250.JPG)
图1:典型的N层应用程序
这里有3个主要的层:客户层(Client Tier),中间层(Middle Tier)和企业信息系统(Enterprise Information System 简称:EIS)层。每一个主要层根据逻辑的不同又分为几层。
客户层包含用户界面和程序接口的容器
表示层包含表述内容的逻辑、处理用户会话、状态管理
业务层包含系统的业务逻辑
综合层包含访问远端程序和数据源的连接器和适配器
资源层包含数据库资料以及像ERP这样的企业信息资源和XML文件
一个在J2EE中典型的网络部署系统的结构就如图所示:
![](http://blog.csdn.net/Develop/ArticleImages/28/28909/CSDN_Dev_Image_2004-6-92142252.JPG)
图2:典型的Web部署系统
在网络部署系统中,决定程序流程,内容创建和内容传递的逻辑是存在于中间层的,因为传统的Web应用程序的主要特点是一个基于客户端浏览器的请求/响应模型。如果要传递界面,系统需要在它通过中间层向客户层传递之前对内容进行以HTML的形式的格式化和编译。对任何表示层的修改都需要向服务器发出请求,做出响应是整个页面的而不是仅仅做出改动的部分。而在传统的网络模型中采用Applet ,JavaScript/DHTML等方法来代替客户层的解决方案,始终没有成为主流,这主要是因为各种各样的技术问题,主要是不同浏览器的兼容问题。
富客户模型可以更好的反映出程序的结构,如下图所示:
![](http://blog.csdn.net/Develop/ArticleImages/28/28909/CSDN_Dev_Image_2004-6-92142254.jpg)
图3:典型的富客户端模型
不像J2EE程序那样,客户端的请求会导致系统生成一个页面再返回客户端,一个RIA可以支持更小的单元或组件,这些组件从小到一个投票问题到一个完整的视图或界面,富客户模型将界面分解成许多的既可以和用户直接交互又可以和服务器进行通信的小单元模块。
这种将应用程序的设计从以一个个相对独立的页面为中心转移到以组件为中心的转变将会使客户层的设计提升到一个新的层次,并且会使客户层变得更加灵活。富客户层不再成为服务器响应的最终端,这同时也使程序的性能得以提高,用户使用的感觉就好像程序不需要和服务器进行通信或者只是偶尔才需要进行通信。
最后一个RIA模型的特点是事件模型,不像传统的模型那样,服务器收到请求后由上至下的创建客户端界面,你不用预测事件的顺序。既然每个组件都是独立的,就没有必要因为一个请求而做出影响整个视图的反应。要使每个组件都具有向服务器传送信息的能力需要每个组建知道如何处理服务器传递回来的信息。在RIA中,客户端和服务器端交互数据是不同步的,这样你就可以控制组件创建信息发送给服务器和处理服务器的响应,可以为更零散的控制去耦和分离程序功能并且组建面向服务的程序结构。
(请注意!引用、转贴本文应注明译者:Rosen Jiang 以及出处:http://blog.csdn.net/rosen)
本章节由网友 azure 翻译,由笔者负责后期的文章润饰。
--------------------------------------------------------------------
RIA设计
现在企业应用程序一般是分层进行设计,也是根据这个组织程序逻辑的。下面就是典型的N层的应用程序模型:
图1:典型的N层应用程序
这里有3个主要的层:客户层(Client Tier),中间层(Middle Tier)和企业信息系统(Enterprise Information System 简称:EIS)层。每一个主要层根据逻辑的不同又分为几层。
客户层包含用户界面和程序接口的容器
表示层包含表述内容的逻辑、处理用户会话、状态管理
业务层包含系统的业务逻辑
综合层包含访问远端程序和数据源的连接器和适配器
资源层包含数据库资料以及像ERP这样的企业信息资源和XML文件
一个在J2EE中典型的网络部署系统的结构就如图所示:
图2:典型的Web部署系统
在网络部署系统中,决定程序流程,内容创建和内容传递的逻辑是存在于中间层的,因为传统的Web应用程序的主要特点是一个基于客户端浏览器的请求/响应模型。如果要传递界面,系统需要在它通过中间层向客户层传递之前对内容进行以HTML的形式的格式化和编译。对任何表示层的修改都需要向服务器发出请求,做出响应是整个页面的而不是仅仅做出改动的部分。而在传统的网络模型中采用Applet ,JavaScript/DHTML等方法来代替客户层的解决方案,始终没有成为主流,这主要是因为各种各样的技术问题,主要是不同浏览器的兼容问题。
富客户模型可以更好的反映出程序的结构,如下图所示:
![](http://blog.csdn.net/Develop/ArticleImages/28/28909/CSDN_Dev_Image_2004-6-92142254.jpg)
图3:典型的富客户端模型
不像J2EE程序那样,客户端的请求会导致系统生成一个页面再返回客户端,一个RIA可以支持更小的单元或组件,这些组件从小到一个投票问题到一个完整的视图或界面,富客户模型将界面分解成许多的既可以和用户直接交互又可以和服务器进行通信的小单元模块。
这种将应用程序的设计从以一个个相对独立的页面为中心转移到以组件为中心的转变将会使客户层的设计提升到一个新的层次,并且会使客户层变得更加灵活。富客户层不再成为服务器响应的最终端,这同时也使程序的性能得以提高,用户使用的感觉就好像程序不需要和服务器进行通信或者只是偶尔才需要进行通信。
最后一个RIA模型的特点是事件模型,不像传统的模型那样,服务器收到请求后由上至下的创建客户端界面,你不用预测事件的顺序。既然每个组件都是独立的,就没有必要因为一个请求而做出影响整个视图的反应。要使每个组件都具有向服务器传送信息的能力需要每个组建知道如何处理服务器传递回来的信息。在RIA中,客户端和服务器端交互数据是不同步的,这样你就可以控制组件创建信息发送给服务器和处理服务器的响应,可以为更零散的控制去耦和分离程序功能并且组建面向服务的程序结构。
(请注意!引用、转贴本文应注明译者:Rosen Jiang 以及出处:http://blog.csdn.net/rosen)
相关文章推荐
- RIA 体系中的设计模式-客户端组件到服务器的通讯(完)(翻译)
- RIA 体系中的设计模式-设计模式(翻译)
- RIA 体系中的设计模式-为什么丰富?(翻译)
- RIA体系中的设计模式
- RIA体系中的设计模式
- 云计算设计模式翻译(二):Circuit Breaker Pattern(断路器模式)
- mongodb指南(翻译)(二十五) - developer zone - 插入对象(二)模式设计(Schema Design)
- java软件体系设计模式-----访问者
- 浅析设计模式之工厂方法模式及一篇相关翻译
- 【翻译】两种高性能I/O设计模式(Reactor/Proactor)的比较
- 设计模式--装饰者模式(在IO体系中的应用)
- 【翻译】Google TV UI 设计模式 (引子)
- 云计算设计模式翻译(三):Compensating Transaction Pattern(事务修正模式)
- .NET Pet Shop 的设计模式与体系结构
- 游戏设计模式--状态机模式(翻译整理)(上篇)
- Java软件体系结构设计模式之结构模式 知识点摘录
- [翻译-ASP.NET MVC]Contact Manager开发之旅迭代4 - 利用设计模式松散耦合
- 云计算设计模式翻译(四):Competing Consumers Pattern(消费者竞争模式)
- 游戏设计模式--状态机模式(翻译整理)(下篇)
- 设计模式之翻译模式