花了近一周的时间，把 iCustomer 大改了一番，其实说来也没有特别大的变化了，修改的东西只不过是一些过去的一些bug和网上朋友们的一些建议，其实重点还是放在改 bug 上，另外就是 Order 这部分系统的领域模型重构，Order 与 OrderItem 之间的关联由原来的 one-to-many 改成了现在的 composite-element 方式，参考了 Hibernate Reference 的内容，从理解上来说这样的关联方式也是比较合适的，有过去的松散的关联方式换成了现在这样紧密的关联方式。通过前面近两个月对 Hibernate 概念更深层次的思考与理解，现在在处理起这样的问题都变得轻松了很多，没有那么多的问题会很让我在开发中卡壳，而且是那种一卡就卡上个好几天不能解决的。当这样的关联关系复杂了以后，Hibernate 的功效才更好的发挥出来了，我们拿关联对象就不用再写一堆方法去拿了，需要的时候去取，Hibernate 就会自动的取帮你取好。实际上这次改 Order 部分时候，很多情况下都是在删过去的代码，过去的方式真的太复杂了，全部要自己手工一个个的去拿，简直就是把 Hibenate 当 SQL 用，从思想上来说，这显然是不正确的。
另外想想看，如果在一个项目中用起 Hibernate 或者使用同样方式的 EJB3 Persistence 真的会存在着太多的风险了。Hibernate 走的是方式上的变革，我们必须去用新的思想去考虑问题，而不是仅仅用用它而已，我们需要从对象建模的角度就开始考虑 ORM 的存在，以对象为中心的方式去组织业务逻辑，而不是以表为中心去组织，刚开始用 Hibernate 的时候，大部分情况还是在考虑表如何如何的，但是用了一段时间以后，发现这样的方式和 Hibernate 真正的核心思想相差太大了。所以说要正确的去用 Hibernate 决不是看了一两本书，做了几个简单的 CRUD 就可以的了，需要在许多复杂关联中经受考验才可以，而一个要很好的去用 Hibernate 的项目，一定是要有这样经验的人去做才可以的，几个刚翻几页书，知道怎么用就去拿 Hibernate 做项目的人真的还是远远不够的，这种情况在 iCustomer 0.1 版本中表现的非常突出，混乱的配置和关联关系，让使用了 Hibernate 后，代码未减反增，我努力在 0.2 的版本中做出一些修改了，当然只是比原来好了一些，离真正理想的情况还是有差距的。当然有空我会把这样的一些经验和大家分享一下，让大家在学习 Hibernate 上少走一些我曾经走过的弯路了。
又用回了 JSF，开始发现这样的方式真的有很多的好处了，而且在 JSF 的使用和经验上有一些积累，用它来建立一个不大的项目经验应该是足够的了。Backing Bean 的方式比 Action 的方式配置文件的数量上要减少了很多，说能够减少到原来的 1/4 甚至更多都不为过了，因为我们一般情况下一个 Backing Bean 对应一个页面，只需要配置一处，而一个页面中如果有很多操作的话 Action 方式就需要配置很多了，比如一个查询页面，查询需要一个 Action，查看查询的一个记录需要一个 Action，删除记录需要一个 Action，修改一条记录又需要一个 Action，算起来正好 1:4，是不是省了很多配置呢，在结合扩展的 Navigation 方式，连 Navigation 都不需要配置了。配置文件真的少了很多了。
用到了一个 Tomahawk 组件中独有的 forceId 属性，不能说有多爽，但是可以让你在写 JavaScript 的时候省了好一些代码了，过去一个组件的 id 生成出来就是 form:cid 的形式，而用了 forcdId = "true" 后，生成出来的 id 就是你在组件的 Tag 中实际定义的值，当然用的时候也要小心了，千万不能重复，包括同一页面中不能重复，也包括一个页面中包含另外一个页面时不能重复 。
posted on 2006-08-21 11:15
steady 阅读(1766)
评论(1) 编辑 收藏 所属分类:
AgileJava