真是佩服自己的杂食能力,
又要新开辟一块战场了,不过整体来说还是对于快速开发和敏捷编程的喜爱。
不过seam有一点让我不是很喜欢,前端用的是JSF。
不知道是不是web bean在jsf里面运作的更好才这样选择的。
我是不太喜欢看着页面里面一堆tag的,对于维护来说,无疑是噩梦。
尽管ror里面也有很多tag,但是脚本语言的清晰度却要远远强于JSF这种复杂的东西。
而且是事件驱动的,暂时还没看到这块的优势在什么地方,
似乎更喜欢ror那种简单清晰的事件驱动模型。
REST也没有摸到,还在找。
不过后端的思想很不错,避免了诸多对象的转来转去。
现在还有一个比较迷惑的地方,看起来entity bean能够直接进入web层是个很不错的选择,
但java ee毕竟是java ee,不是ror,
当我希望把web层剥离出来单独部署的时候,怎么减少entity bean的串行化传输量和解决lazy load的问题,
好像还没有想明白。
难道在seam bean中的注入时定义一个体积较小的vo对象在处理,似乎回到了po转vo的模式。
再找找答案吧,
整体来说seam值得一看,gavin king确实是个天才。
又要新开辟一块战场了,不过整体来说还是对于快速开发和敏捷编程的喜爱。
不过seam有一点让我不是很喜欢,前端用的是JSF。
不知道是不是web bean在jsf里面运作的更好才这样选择的。
我是不太喜欢看着页面里面一堆tag的,对于维护来说,无疑是噩梦。
尽管ror里面也有很多tag,但是脚本语言的清晰度却要远远强于JSF这种复杂的东西。
而且是事件驱动的,暂时还没看到这块的优势在什么地方,
似乎更喜欢ror那种简单清晰的事件驱动模型。
REST也没有摸到,还在找。
不过后端的思想很不错,避免了诸多对象的转来转去。
现在还有一个比较迷惑的地方,看起来entity bean能够直接进入web层是个很不错的选择,
但java ee毕竟是java ee,不是ror,
当我希望把web层剥离出来单独部署的时候,怎么减少entity bean的串行化传输量和解决lazy load的问题,
好像还没有想明白。
难道在seam bean中的注入时定义一个体积较小的vo对象在处理,似乎回到了po转vo的模式。
再找找答案吧,
整体来说seam值得一看,gavin king确实是个天才。
既然你支持ZD和抵制奥运,我只好和你说再见notepad++
谈Groovy为Java做单元测试

2008/08/07 11:26 | by 