没有合适的资源?快使用搜索试试~ 我知道了~
一个真正面向对象的JavaEE或J2EE系统,应该是一个围绕领域模型的多层架构,以面向对象OO思维进行领域模型提炼和重构,继续以OO思维进行表现层和持久层的配置实现,才能寻找到一条Java系统快速有效高质量的解决之道。
资源推荐
资源详情
资源评论
Java EE/J2EE 面向对象编程之道
一个真正面向对象的 JavaEE 或 J2EE 系统,应该是一个围绕领域模型的多层架构,以面向
对象 OO 思维进行领域模型提炼和重构,继续以 OO 思维进行表现层和持久层的配置实现,
才能寻找到一条 Java 系统快速有效高质量的解决之道。
OO 思维
经常看到不少人抱怨 Java EE/J2EE 中配置太复杂,烦琐,不简单易学,其实所谓简单易
学是取决于你是否有 OO 思维方式。
表现层的界面表单中通常是一些离散数据,也就是单个字段数据,通过 Struts 等框架提供
ActionForm 以及标签库,将这些单个字段数据封装起来和业务层的 Domain Model 进行
了映射,因此,表现层的主要编程工作就是映射配置。
持久层是将 Domain Model 对象保存到数据库中,过去使用 JDBC,我们要逐个打开这些
Model 对象,然后每个字段逐个保存到数据库中,如果说表现层框架是实现离散数据 封装,
那么持久层实现的是反方向:拆封。Hibernate 是一个持久层 O/R mapping 框架, 也就
是在对象和关系数据库之间进行映射的框架,EJB 的 CMP 也是类似道理,因此,持久层的
主要编程工作也是映射配置。
表现层和持久层这种配置工作就如同打包邮寄一样:你首先要将你的单件用一个箱子包装
起来,达到目的地,这个箱子被打开,单件被逐步取出。表现层和持久层这样做的目的是
保证中间业务层完全面向对象,他们都是和一个个对象打交道,而不是单件数据字段。
在一个真正面向对象的系统中,表现层和持久层主要工作就是配置,而且是映射
mapping 的配置。下面的问题就是:如何解决映射配置简单而且易用,如果拥有正确的
指导配置的思维,那么配置工作就容易简单多,否则,就倍感配置复杂。
其实那些感觉 Java 配置复杂的人其实他并没有完整的 OO 思维。为什么这么说呢?以
ORM(Hibernate)配置简易方式说明:
配置的简要之道
首先,配置是映射配置,顾名思义,也就是在两者之间做协调,牵线搭桥,说白了,就是
做红娘,但和做红娘又有些区别,做红娘可以要求双方做些改变,互相迁就,但是做映射
配置,则不能这样,因为那样做就可能做出和需求要求不一样的东西。
以持久层映射配置来说:双方是指 Domain Model 对象和关系数据表,如果感觉在两者
之间配置映射很困难,双方做些改变,但是有可能 需求不答应,你一旦为协调而作出的改
变可能偏离需求实现的目标,最后作出的系统面貌全非,根本不是客户所需要的。
那么怎么办?很显然,紧扣需求,反映需求的那一方坚决不要变动,那么 Domain Model
和关系数据表哪一方反映需求呢?按照 OO 分析,当然是 Domain Model,Model 对象
我们是依据 Evans Model 等模型驱动设计 MDD 概念设计出来,他们是需求的代表。
很显然,我们的映射配置必须顺着 Model 对象这个思维来配,对于名词式的 Model,关
联无外乎是其主要关系,当然还有继承,因此,象 Hibernate 这些映射配置语法也是面向
这些主要对象关系的。
表现层配置也是同样的道理,需要将 Domain Model 配置成界面表单,在实际中,我们
有可能采取的是通过界面收集需求,因此,这个映射配置过程也是考验 Model 对象是否提
炼正确与否,有可能发现 Model 不能实现一些界面需求功能,这时反过来必须修改我们的
Model,而不是仅仅在表现层这个技术层面做些补救措施就糊弄过去。
Java EE/J2EE 系统开发过程敏捷的迭代是必然的。没有一个天才能够一步到位提炼出兼顾
界面和数据表以及需求的统一模型出来。
总之,完成一个真正面向对象的 Java EE/J2EE 系统,必须抓住领域建模和具体框架熟练
配置两点,只有这样才能保证 Java 项目成功实施。最关键的是提炼出反映出业务系统的领
域模型: Domain Model,完成业务建模后,就是依赖 Struts/Hibernate 等配置分配将
Model 映射到界面和数据库,其实就是将业务模型移植到计算机领域并能够正确运行。
高聚合和低关联
如果一个系统都被设计成相互没有任何不包含的单个对象,很显然是不能正确反映实际需
求的,万事万物都是有其部分组成的,例如窗户由玻璃和框架组成,人是由胳膊、腿等身
体部分组成,现实世界中,事物之间总是存在关系,聚合和组成是最常见的。
例如订单,一个订单 Orders 中由客户名称和地址,订购的产品品种和数量,客户名称和
地址,我们可以抽象为 Customer 来代表,产品我们使用 Product 来代表,由于一个订
单中可能订购了多个产品,很显然,一个订单对象中应该有多个 Product 对象,而且每个
Product 的数量不一样, 我们将 Product 和其数量再抽象包装成 OrderLine 订单条目对
象,这样,订单中包含多个订单条目,而且订单条目只有依赖某个订单,是其组成部 分,
是一种强聚合关系,不是普通的聚合或关联关系。而 Customer 和 Order 之间是一种聚合
关系,如果订单没有客户信息,就不成为订单了。
%
下面再以用户 User 这个对象为例,用户 User 可能拥有很多动态属性,一些属性需要运行
时动态确定,用户和动态属性是一个整体和部分的聚合关系; 每个用户都必然属于某个部
门,因此,用户和部门属性对象之间也是一个整体和部分的聚合关系,这两种聚合关系不
同之处在于:前者一个用户可能有多个动态属 性,是 1:N 关系;部门 Dept 和用户 User
之间是 1:N 关系,一个部门中可能有多个用户,反过来说,对于用户 User 来说:它和部
门 Dept 之间是 N:1 关系。
%
剩余10页未读,继续阅读
资源评论
weixin_38548704
- 粉丝: 3
- 资源: 931
上传资源 快速赚钱
- 我的内容管理 展开
- 我的资源 快来上传第一个资源
- 我的收益 登录查看自己的收益
- 我的积分 登录查看自己的积分
- 我的C币 登录后查看C币余额
- 我的收藏
- 我的下载
- 下载帮助
最新资源
- Screenshot_20240427_031602.jpg
- 网页PDF_2024年04月26日 23-46-14_QQ浏览器网页保存_QQ浏览器转格式(6).docx
- 直接插入排序,冒泡排序,直接选择排序.zip
- 在排序2的基础上,再次对快排进行优化,其次增加快排非递归,归并排序,归并排序非递归版.zip
- 实现了7种排序算法.三种复杂度排序.三种nlogn复杂度排序(堆排序,归并排序,快速排序)一种线性复杂度的排序.zip
- 冒泡排序 直接选择排序 直接插入排序 随机快速排序 归并排序 堆排序.zip
- 课设-内部排序算法比较 包括冒泡排序、直接插入排序、简单选择排序、快速排序、希尔排序、归并排序和堆排序.zip
- Python排序算法.zip
- C语言实现直接插入排序、希尔排序、选择排序、冒泡排序、堆排序、快速排序、归并排序、计数排序,并带图详解.zip
- 常用工具集参考用于图像等数据处理
资源上传下载、课程学习等过程中有任何疑问或建议,欢迎提出宝贵意见哦~我们会及时处理!
点击此处反馈
安全验证
文档复制为VIP权益,开通VIP直接复制
信息提交成功