JEECG的应用感想

quainty

本文简要谈谈这段时间对JEECG的应用感想。（没有经过整理，乱了点，仅供参考。）

JEECG确实很省事，对于简单应用，如果设计好数据库，基本写不了什么代码，差不多可以达到作者的节省60%的预期。

对于简单的基本表的增删查改操作，非常好，可能还不止节省60%，都快要0编码了。而且因为自定义标签，代码很简洁。

（复杂系统的话，用这个为原型，也很容易做出一套东西）

作者把基本应用的基本操作差不多都想到了，不容易啊。


不过个人感觉封装得有点过了，在下面功能方面稍显不足：（我暂时只对easyUI的datagrid部分做了些研究，其它部分以后再说，以下也大部分集中于此讨论）

1）多条件查询。现在利用算定义标签，封装了datagrid的支持。作者可能今后不想用Easyui了，想通过重写标签实现直接转换，但是估计会比较困难，或许大部分项目意义也不会太大。里头对条件查询基本限制在了单条件了，条件组合不好直接用。个人感觉好像是V2里的那种layout支持（把条件放north里了）用户体验要好些。

2）想到一个具体点儿的，datagrid的formater项限在了日期格式里了，少了之前的EASYUI应用的灵活性，建议改成dateformat或者dataformat, 把formater还原为自定义处理的扩展。（可以自己写处理函数）中间好像看过别的一些标签处理，几个属性项的关系稍有点混乱。

    另外，点击之后，把点的行用全局变量记下来，之后再处理，这种作法不太好，容易出BUG（好像切换TAB之后就会出问题）

而且全局变量的命名不够严谨，万一被用户重定义就麻烦了。（这个应该可以直接用选中项进行处理吧，可能不太了解作者的初衷）

好像还有好几个全局变量，暂时没细看，觉得象个补丁。

3）可能是DEMO用的自动生成方法限制了，感觉系统对于spring的分层处理反而局限了。

第一个是controller中直接用数据库的实体对象作为页面注入的对象，不够灵活（在多表连接查询的时候，就不好用）。建议自动生成的时候考虑把pagemodel与entity分开处理。（JEECG系统，与sypro（孙宇大侠作品）看上去有瓜葛，不知谁先做的，没考究，个人感觉sypro的要稍清晰一些）。虽然sypro中用的pagemodel个人感觉也是entity的重复，但是在多表操作时要灵活许多。另外，个人见解：其实pagemodel和entity实体没什么关系，只是想提交查询条件，实际应该有一个 grid的分页处理的几个项加上需要作为查询条件的项目就可以（这个完全可以让自动生成实现，不用封装到框架中。这样生成后，用户还可以自由扩展）

第二个是service中，现在基本没处理了，作者想通过页面直接写好数据项，然后直接在controller中处理，通过通用的service再调到通用的dao。数据处理太过追求service和dao的通用性。在多表查询中处理比较受限。建议可以把DAO通用，但是对于查询条件，表关联的封装放到service中，页面部分不要太过考虑后台处理的数据逻辑。个人觉得，比如把Criteria的各种处理放Service中，DAO中直接用处理好的Criteria去处理数据库可能要好一些。

4）关于自动生成，个人觉得既然生成的代码不能保证100%生成，就自由一些为好。多生成些代码，应该没什么，只要好修改，结构清晰就可以了（大不了加些注释：）

不过这样JSP要稍微大些（其实实际运行也就多些回车、空格TAB之类的字符）

写着写着，思绪乱了，呵呵，下次再补充吧。

孙小宝

封装的确实有点过头了，这样的话只适合某些特定场合了

jeecg_scott

多谢大家支持，灵活性的确很重要，这个也是我在封装的时候一直考虑的问题！
V3版本是经过了项目实战的，所以灵活性，应该不会有大的问题