Jdon 框架能解决什么问题?
搞过数据库系统的人都知道,数据库系统中大量的基本功能无非是数据表的 CRUD
增删改查和批量分页查询,Jdon 框架以 J2EE 设计理念将这个看似简单功能开发过程抽
象出来,放在框架中,并且随着应用程序一起运行,提供优化性能提升等。
当你只需要快速建立一个软件应用系统,Jdon 框架正好适合你。
如果你希望马上手一个Hello World的案例,可直接到“
开发一个简单Jdon应用系统”
章节。
请注意:Jdon 框架不是面向数据库的;而是面向模型分析设计(OOA/OOD)。Jdon
框架是基于如下一个软件生产环节中:
需求 Use case 分析;使用 Rose 或 Together 等 UML 工具;
面向对象的模型提取,域建模的确立,可使用 UML 的类图表达。
模型CRUD等基础功能快速完成以及构件/组件库组装;如果在这一过程中使用Jdon
框架可提前保质保量完成,Jdon之类快速开发框架是基于真正松耦合的设计架构,这样
在以后迭代过程中才能应需求改变。软件松耦合和快速性讨论见:
http://www.jdon.com/artichect/coupling.htm
反馈给用户确认;根据用户需求修改模型或界面或数据库或逻辑,因为有 Jdon 等
框架形成架构的松耦合性,修改一处不会影响太多无关部分,具有好的可维护和可拓展,
再次给用户确认;进入下一个循环。
快速开发框架和代码生成工具的区别:
软件生产是一个产品生成过程,只要是产品就要有质量要求,如果质量单纯靠人工
保证是不行的,必须靠自动化的生产设备,而开发框架和组件或构件库则就是可以保证
质量的生产设备;当然只有生产设备也是不行的,必须有良好的产品设计,必须符合客
户要求,符合市场需求,那么产品设计就是域建模设计,域建模专家就象工厂的产品设
计师或工艺师一样。
那么除了生产设备和产品图纸是不是就可以生长出高质量软件?不是,必须有不同
级别软件人员,以及对他们的管理,也即软件工程管理,软件工程管理是和生产设备是
互补的,如果生产设备自动化程度高,对人员要求低,管理就相对容易一些。
所以,目前对于软件生产这样一个产业,最重要的是摆脱依赖人工的局面,形成生
产设备高度自动化。
当然,过分重视生产设备自动化的极端是必须指出的,这也是代码生成工具的产生
原因,在目前,第一个阶段“松耦合”还没有完成,就想进入共产主义,显然有些急躁。
开发框架是基于软件最大追求松耦合基础上诞生,实现真正高质量;而代码生成工
具则可能生成好或坏的代码。
软件产品生产=产品设计图(域建模)+自动化生产设备(开发框架或组件库)+
不同级别的开发人员+软件工程管理。开发框架需要人员参与编程;而代码生成工具夸
大生产设备作用。
如果你希望马上手看一个Hello World的案例,可直接到“
开发一个简单Jdon应用系
统”章节。
技术背景
Java EE/J2EE 基本概念
J2EE 可以说指 Java 在数据库信息系统上实现,数据库信息系统从早期的 dBase、
到 Delphi/VB 等 C/S 结构,发展到 B/S(Browser 浏览器/Server 服务器)结构,而 J2EE
主要是指 B/S 结构的实现。
J2EE 又是一种框架和标准,框架类似 API、库的概念,但是要超出它们。
J2EE 是一个虚的大的概念,J2EE 标准主要有三种子技术标准:WEB 技术、EJB
技术和 JMS,谈到 J2EE 应该说最终要落实到这三个子概念上。
这三种技术的每个技术在应用时都涉及两个部分:容器部分和应用部分,Web 容
器也是指 Jsp/Servlet 容器,你如果要开发一个 Web 应用,无论是编译或运行,都必须
要有 Jsp/Servlet 库或 API 支持(除了 JDK/J2SE 以外)。
Web 技术中除了 Jsp/Servlet 技术外,还需要 JavaBeans 或 Java Class 实现一些功能
或者包装携带数据,所以 Web 技术最初简称为 Jsp/Servlet+JavaBeans 系统。
谈到 JavaBeans 技术,就涉及到组件构件技术(component),这 是 Java 的核心基础
部分,很多软件设计概念(设计模式)都是通过 JavaBeans 实现的。
JavaBeans 不属于 J2EE 概念范畴中,如果一个 JavaBeans 对象被 Web 技术(也就
是 Jsp/Servlet)调用,那么 JavaBeans 就运行在 J2EE 的 Web 容器中;如果它被 EJB
调
用,它就运行在 EJB 容器中。
EJB(企业 JavaBeans)是普 通 JavaBeans 的一种提升和规范,因为企业信息系统开
发中需要一个可伸缩的性能和事务、安全机制,这样能保证企业系统平滑发展,而不是
发展到一种规模重新更换一套软件系统。
J2EE 集群原理: http://www.jdon.com/jive/article.jsp?forum=121&thread=22282
至此,JavaBeans 组件发展到 EJB 后,并不是说以前的那种 JavaBeans 形式就消失
了,这就自然形成了两种 JavaBeans 技术:EJB 和 POJO,POJO 完全不同于 EJB 概念,
指的是普通 JavaBeans,而且这个 JavaBeans 不依附某种框架,或者干脆可以说:这个
JavaBeans 是你为这个应用程序单独开发创建的。
J2EE 应用系统开发工具有很多:如 JBuilder、Eclipse 等,这些 IDE 首先是 Java 开
发工具,也就是说,它们首要基本功能是可以开发出 JavaBeans 或 Java class,但是如果
要开发出 J2EE 系统,就要落实到要么是 Web 技术或 EJB 技术,那么就有可能要一些
专门模块功能,最重要的是,因为 J2EE 系统区分为容器和应用两个部分,所以,在任
何开发工具中开发 J2EE 都需要指定 J2EE 容器。
J2EE 容器分为 WEB 容器和 EJB 容器,Tomcat/Resin 是 Web 容器;JBoss 是 EJB
容器+Web 容器等,其中 Web 容器直接使用 Tomcat 实现的。所以你开发的 Web 应用程
序可以在上面两种容器运行,而你开发的 Web+EJB 应用则只可以在 JBoss 服务器上运
行,商业产品
Websphere/Weblogic 等和 JBoss 属于同一种性质。
J2EE 容器也称为 J2EE 服务器,大部分时它们概念是一致的。
如果你的 J2EE 应用系统的数据库连接是通过 JNDI 获得,也就是说是从容器中获
得,那么你的 J2EE 应用系统基本与数据库无关,如果你在你的 J2EE 应用系统耦合了
数据库 JDBC 驱动的配置,那么你的 J2EE 应用系统就有数据库概念色彩,作为一个成
熟需要推广的 J2EE 应用系统,不推荐和具体数据库耦合,当然这其中如何保证 J2EE
应用系统运行性能又是体现你的设计水平了。
高质量的 Java 企业系统
衡量 J2EE 应用系统设计开发水平高低的标准就是:解耦性;你的应用系统各个功
能是否能够彻底脱离?是否不相互依赖,也只有这样,才能体现可维护性、可拓展性的
软件设计目标。
为了达到这个目的,诞生各种框架概念,J2EE 框架标准将一个系统划分为 WEB
和 EJB 主要部分,当然我们有时不是以这个具体技术区分,而是从设计上抽象为表现
层、服务层和持久层,这三个层次从一个高度将 J2EE 分离开来,实现解耦目的。
因此,我们实际编程中,也要将自己的功能向这三个层次上靠,做到大方向清楚,
泾渭分明,但是没有技术上约束限制要做到这点是很不容易的,因此我们还是必须借助
J2EE 具体技术来实现,这时,你可以使用 EJB 规范实现服务层和持久层,Web 技术实
现表现层;
EJB 为什么能将服务层从 Jsp/Servlet 手中分离出来,因为它对 JavaBeans 编码有强
制的约束,现在有一种对 JavaBeans 弱约束,使用 Ioc 模式实现的(当然 EJB 3.0 也采
取这种方式),在 Ioc 模式诞生前,一般都是通过工厂模式来对 JavaBeans 约束,形成一
个服务层,这也是是 Jive 这样开源论坛设计原理之一。
由此,将服务层从表现层中分离出来目前有两种可选架构选择:管理普通 JavaBeans
(POJO)框 架 (如 Spring、JdonFramework)以及管理 EJB 的 EJB 框架,因为 EJB 不只是
框架,还是标准,而标准可以扩展发展,所以,这两种区别将来是可能模糊,被纳入同
一个标准了。
但是,通常标准制定是为某个目的服务的,总要牺牲一些换取另外一些,所以,这
两种架构会长时间并存。
前面谈了服务层框架,使用服务层框架可以将 JavaBeans 从 Jsp/Servlet 中分离出来,
而使用表现层框架则可以将 Jsp 中剩余的 JavaBeans 完全分离,这部分 JavaBeans 主要
负责显示相关,一般是通过标签库(taglib)实现,不同框架有不同自己的标签库,Struts
是应用比较广泛的一种表现层框架。
这样,表现层和服务层的分离是通过两种框架达到目的,剩余的就是持久层框架了,
通过持久层的框架将数据库存储从服务层中分离出来是其目的,持久层框架有两种方
向:直接自己编写 JDBC 等 SQL 语句(如
iBatis);使用 O/R Mapping 技术实现的 Hibernate
和 JDO 技术;当然还有 EJB 中的实体 Bean 技术。
持久层框架目前呈现百花齐放,各有优缺点的现状,所以正如表现层框架一样,目
前没有一个框架被指定为标准框架,当然,表现层框架现在又出来了一个 JSF,它代表
的页面组件概念是一个新的发展方向,但是复杂的实现让人有些忘而却步。
最后,你的 J2EE 应用系统如果采取上面提到的表现层、服务层和持久层的框架实
现,基本可以在无需深刻掌握设计模式的情况下开发出一个高质量的应用系统了。
还要注意的是: 开发出一个高质量的 J2EE 系统还需要正确的业务需求理解,那么
域建模提供了一种比较切实可行的正确理解业务需求的方法,相关详细知识可从 UML
角度结合理解。
当然,如果你想设计自己的行业框架,那么第一步从设计模式开始吧,因为设计模
式提供你一个实现 JavaBeans 或类之间解耦参考实现方法,当你学会了系统基本单元
JavaBeans 或类之间解耦时,那么系统模块之间的解耦你就可能掌握,进而你就可以实
现行业框架的提炼了,这又是另外一个发展方向了。
以上理念可以总结为一句话:
J2EE 开发三件宝: Domain Model(域建模)、patterns(模式)和 framework(框架)。
组件框架比较
EJB2/EJB3
Spring
Framework
Jdon Framework
灵活
性
(松耦合)
EJB3比 EJB2更
具灵活性,EJB3 支
持应用系统 POJO
支持应用系统
POJO,框架基础功能
不能替换
支持应用系统
POJO,框架本身可
分离配置,定制性
更强
功能
完整性
全面,支持异步
JMS 分布式事务
较为全面。有自
己的表现层和持久层
模板,可支持异步
基本完整,表
现层借助 Struts 实
现。有自己简单的
持久层模板
单台
性能
一般,批量查询
等大数据量业务处
理须小心,存在本地
不透明缺陷。
一般,框架本身
组件无性能提升极
致,应用程序可配置
cache/Pool
好,框架本身
组件使用缓存提升
性能,应用程序可
配置 cache/Pool,批
量查询专门优化,
适合实时性并发性
要求较高应用
可伸
缩性
可支持多台服务器
分布式计算。
不支持,可依靠
EJB 实现
不支持,可依
靠 EJB 实现
开发
效率
学习曲线长,导
致熟练掌握难。借助
商业开发工具可加
快熟练者的开发速
度。
较为复杂,可挑
选只适合自己的功能
实现。当组件很多时,
需要照顾这些组件之
间调用关系。
简单快速,表
现层编码很少。当
组件个数很多时,
无需照顾它们之间
的调用关系
系统
规模
EJB2 适合大型
系统;EJB3 适合中大
型系统
适合中小型系统
适合小中型系
统,和 EJB 无缝结
合,可借助 EJB 支
持中大型系统
重量
级别
重量,正在减肥
轻量偏重,有可
能继续增肥
最轻量,恪守
简单快速原则
详细文章见:
http://www.jdon.com/artichect/java_ee_architecture.htm