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关系。

　　通过以上建模过程，我们基本搞清楚两件事：这个领域中存在哪些模型对象？按照evans的ddd理论，哪些是实体，哪些是值对象；然后我们必须搞清楚那些聚合关系，他们是整体部分的关系，用来共同组成一个完整对象的。

持久层hibernate聚合实现

　　在持久层我们需要做的主要工作就是将上述domain model 进行持久化映射配置，以user为例，user是一个实体，我们配置user.hbm.xml如下：

< hibernate-mapping>
　　< class name="sample.model.user" table="testuser">
　　　　< id name="userid" type="java.lang.string" >
　　　　< generator class="assigned"/>
　　< /id>

　　< property name="username" type="java.lang.string">
　　　　< column name="name" />
　　< /property>

　　< !--表示和部门dept之间是一种多对一关系 -->
　　 < many-to-one cascade="save-update" name="dept"
　　　　 class="sample.model.dept" column="categoryid" />

　　< !-- 表示和用户属性userpropperty之间是一种1对多关系-->
　　< bag name="userprops" inverse="true" cascade="all" >
　　　　< key column="userid" />
　　　　< one-to-many class="sample.model.userproperty" />
　　< /bag>　　
< /class>

< /hibernate-mapping>
 

　　在user的映射配置文件中，我们很自然地表达了上节model之间的聚合关系，通过hibernate配置，我们将模型对象之间的关系可以持久化保存到数据库中了，也就是可以永久维持这种关系，实际上，现实世界中也是这样的，部分和整体的关系是一直存在，除非这个整体这个对象不存在，而且修改部分对象内部值，必须通过整体这个对象。

　　在user配置中，我们并没有去做任何关系数据表testuser的设计和设定，因为我们知道，当user.hbm.xml配置完成后，这个j2ee系统部署发布到j2ee容器中时，hibernate会根据这个配置自动创建数据表testuser，数据表的建立已经是一个部署调试阶段的、技术层面的具体工作。

hibernate重要的父子关系

　　hibernate在处理user和userproperty这样一对多的父子关系时，具体实现起来要有一些具体细节必须注意，而且hibernate2和hibernate3两个版本是不一样的：

　　当我们需要只通过一句话session.save(user)或session.update(user)就能完成user和它其中多个userproperty都能自动保存或更新时（必须指定cascade="all" 或save-update），尤其是update(user)更新时，其子集合userprops属性中可能有一些userproperty是修改过的，一些userproperty则是新增的，对于新增要使用insert语句；而对于修改则使用update语句，当我们笼统地调用一句update(user)时，那么hibernate是如何判断这个user中子集合中哪些是修改？哪些是新增的？

　　hibernate是通过主键来判断的，也就是说，通过userproperty的主键来判断该对象是修改？还是新增。最关键的是：这个主键必须由hibernate自动产生，如果你想自己指定子对象userproperty主键，那么就有可能很多麻烦，这个麻烦是出其的麻烦，无法判断具体原因。所以，在简单方便的道路上迈错一步就是万丈深渊。下面是userproperty的映射配置：

< hibernate-mapping>

　　< class name="sample.model.userproperty" table="userprops">
　　　　< id name="propid" type="java.lang.string" >
　　　　　　< generator class="uuid.hex"/>< !-- 不能为assigned-->
　　　　< /id>　　
　　< property name="name" />　　
　　< property name="value" />

　　< !-- 为提升性能而设定 -->
　　< many-to-one name="user" column="userid" not-null="true"/>
< /class>