实在不太愿意去研究什么Java框架了,以前什么都学,结果弄得身心俱疲,不怎么愿意再下功夫了,还不如学好操作系统,学好数据库,那些东西几十年了基本上没有变化,而Java框架几乎每天都不一样,每天都有新的框架出现,每一个都是那么吸引人,可是再深入使用后总要发现又有更多的问题要去解决,所以框架就想办法去解决这些问题,结果原本简单的东西也复杂了。

现在的框架太多了,结合使用可不是每个人都搞得来了,很少有人有那么多时间,把所有的框架测试一边,然后结合在一起使用,Matt Raible的AppFuse给大家一个结合使用的Demo,还提供了一些开发模式,使用他提供的开发模式作一些例子非常快,可是如果让我们做一些东西,却不是那么简单,我们有太多事情不知道。

以前认真研究过AppFuse的各个部分,其中吸引人但也最乱的部分就是许多自动过程。Matt Raible确实把Ant使用的出神入化,后来我遇到不会的Ant用法,我也尝试在AppFuse里查找可能的用法。另一个就是自动代码生成机制,大多是用XDoclet完成,但是撰写自己XDoclet生成模版确实不是件容易的事,当页面有许多特殊情况的时候,这种自动生成机制实在只能作为一个辅助手段,只可以作为起始的模版,以后我们如果修改了模型,我们很难再通过这种生成机制生成页面和类,所有的工作我们要学着自己去作,这时候生成的代码就是一场噩梦,维护更加复杂。

当然有一些框架可以弥补这种生成的代码不好维护的问题,如Tapestry,另一个类似于AppFuse,号称MDA框架的Trails也使用这个作为前台现实的框架,可见Tapestry已经在这方面有一定的改善。不过Trails还是刚刚起步,未来还很难说。

我想,在对Ant和XDoclet还并不熟练时,在没有这种开发意识的情况下,还很难使用AppFuse来开发,但是AppFuse对我们来说有很多参考价值,它可以教会我们如何使用Spring,它可以教会我们如何写TestCase测试,也给我们很多启发,怎样才能尽可能的自动化代码工作,怎样优化我们的工作流程。

我现在一直关注着
Trails,在许多人看来TrailsAppFuse很类似,不知道它会发展到什么程度,它至少在表面看来比AppFuse简单,好像要简单一些,这是我们最需要的。


评论

该日志第一篇评论

发表评论

评论也有版权!