Java框架

得益于Java的反射特性,Java的框架资源非常丰富。下面会整理一下常用的,已经不好用的框架列表及原因。

设计得不太好的框架

JFinal

我曾经试过将一个Java项目用JFinal来做,当项目发展到一定程度了,就会严重感受到JFinal的过度包装所带来的灵活性或稳定性缺失。主要来说有这些方面的缺陷,当然这也是别人会用它所认为的优点。

  1. 数据库DAO层,使用map代替了传统的Entity模型。这导致数据库字段需要大量手写,也不利于代码重构。对于过度靠约定数据库字段到Java字段的映射,也会导致灵活性降低,也不够直观看出数据库字段和Java字段的实际映射关系。对于中大型Java项目,DAO层的稳定非常重要。这也是为什么php,python,nodejs之类的动态语言,不适合做中大型项目的原因。

    JFinal的Entity对象,需要继承自Model,从设计上,应该把Entity设计成一个纯粹的POJO,不要让它去继承一个基类获得方法上的特性。这一点Spring的方向则是对的,Spring尽可能地让DO、Controller变成是一个纯粹的、无入侵的Java Bean。

  2. Web层的参数需要自己去request中拿,拿的逻辑遍布在代码中,这点不如Spring MVC注解在方法中直观。

  3. 所谓的零配置,实际上是依靠大量的约定来做到。对于约定代替配置这个事情,我是比较谨慎的。约定的东西如果不被业界所共同认知,并成为计算机行业的常识的话,就会加大学习成本和降低灵活性,同时使得维护程序是难以有线索跟踪。一开始是方便了,但是出来混始终是要还的,将积累下技术债务。

    此外,我认为xml或properties配置文件,不是依靠Java的代码方式,就等于是免配置了,实际上只不过写在代码里了。xml或properties文件还是有必要存在的,但它们应该尽可能少改动,不应该因为增加或减少Java Bean而需要频繁编辑。

文档更新时间: 2018-11-10 20:09   作者:nick