J2EE体系结构
ª J2EE应用服务器提供了许多附加的服务,J2EE开发人员会被J2EE所提供的这些选择所
淹没,或者说会禁不住诱惑去使用不合适解决问题的基础结构。
ª企业级体系结构的目标
1) 是坚固的
2) 是可工作和可缩放的
3) 利用OO设计原理:虽然许多“J2EE模式”是很有价值的,但经典(非技术特有)的设计模式更有价值。
4) 避免不必要的复杂性:做“可能管用的最简单的事”。
5) 是可维护和可扩展的
6) 按时交付
7) 测试容易
8) 提倡重用
9) 对多种客户类型的支持
10) 可移植性
ª 分布式模式是实现坚固而又可缩放的应用的一种方法,但倘若有选择的余地,最好是通
过选择一个非分布式的解决方案来避开分布式应用的各种复杂性。
ª 无论采用何种数据存取策略,通过一个抽象层将业务逻辑和数据存取逻辑的细节分离开
来是最好不过的。
ª 只要遵循编程到接口,而不是编程到具体类的优良OO设计原理,我们就可以把数据存
取细节与应用的其余部分隔离开。
ª 经验以及证明了将企业级系统明确的划分成多个层的价值,这确保了责任的明确划分。
ª J2EE的3层体系结构是各类系统中的经验结晶,具有3个或3个以上层的系统已经证明
比期内没有中间层的客户-服务器系统具有更大的可缩放和灵活性。
ª 在一个设计完备的多层系统中,每一层应该只依赖于它下面的那一层。例如,对数据库
的更改不应该要求对Web接口的更改。
ª 每一层所特有的东西应该向其他曾隐藏起来。
ª 以上两个原则确保了应用修改起来容易,同时修改由不级联到其他层。
Ø J2EE的3层体系结构
1) 企业信息系统层(EIS)
包括数据库管理系统和遗留的主机应用,EIS层位于J2EE服务器的控制之外,尽管该服务器的确已一种标准方式管理事务和连接。
2) 中间层
含有应用的业务对象
3) 用户接口层(UI,也称作Web层)
Ø 非分布式体系结构
同一个J2EE Web容器提供许多应用所需要的整个基础结构,UI层和中间层运行在同一
个JVM中。
Ø访问本地EJB的Web应用
一个应用被部署在一个集成的J2EE应用服务器中且该服务器运行在单个JVM中,通
过本地接口来保证EJB的UI层对象访问。
Ø 具有远程EJB的分布式应用(分布式体系结构)
“经典”的J2EE体系结构,通过EJB及使用EJB组件,使用不同的JVM来物理和逻
辑地划分中间层。
Ø 暴露Web服务接口的Web应用(分布式体系结构)
ª 给任意一个J2EE应用增加了一个暴露Web服务的Web服务接口和一个实现必要协
议的传输层。远程接口一般被添加到一个现有的应用上,而不是被内建到该应用的结构
上。
ª Web服务标准(如SOAP)的出现意味着J2EE应用不再束缚与使用RMI和EJB来
支持远程客户。
ª Web层(UI层)是一个位于中间层业务接口之上的独立层。这保证了Web层能在不更改
业务对象的情况下被修改,已经业务对象能在不引用Web层的情况下被测试。
ª Web层是有可能最常遭到修改的部分,许多因素都会导致一个Web站点外观和感觉方面
的显著修改。保证Web层对变化作出反应的关键,是保证在业务对象的表式与逻辑控
制和访问之间有一个明确的分离。
ª 要想在表示与逻辑之间实现分离,一种已经得到证明的方法是给Web应用使用MVC体
系结构模式。
ª 如此实现的宗旨:对于显示层,让它去该,我的业务层不随波逐流。即将显示和业务之
间的偶合性降低。
ª MVC
1) 模型数据或应用对象—不含有与表示相关的任何代码。模型时一个暴露数据的Java组件,模型对象不应该知道如何从业务对象中间所数据。视图的再现将永远不会因检索数据故障之类的原因而失败,这极大的简化了表率曾中的错误处理。
2) 视图对象执行模式数据的屏幕表示,J2EE中的视图构件通常是JSP页面。
3) 控制器对象对用户输入作出反应,并据此更新改模型。控制器不实现业务逻辑(这将会侵犯中间层的责任),控制器属于UI层。
ª 表示与逻辑之间的分离对实现能够响应可变表示需求的可维护Web应用来说至关重要。
ª 一个典型的J2EE中的MVC实现包括使用一个标准的控制器服务器小程序作为进入整个
应用或部分应用的统一入口点。这个入口点从应用特有的多个请求控制请重选择一个来
处理请求(映射将一配置形式在Java代码外部进行定义。)