最近，利用EOVA开发了一个科研人员日常管理助手V1.0版。

该版本主要针对科研人员日常的项目经费相关业务展开，具体功能包括：

（1）团队及项目相关人员信息管理；

（2）项目类型管理；

（3）经费科目管理；

（4）项目基本信息管理；

（5）项目预算管理；

（6）针对项目参与人员经费使用划分的人员经费分配管理；

（7）收支流水账记账管理；

（8）相关查询统计分析，包括人员经费使用情况统计、项目预算执行情况统计、项目经费收支情况统计等。

 

该软件V1.0一定程度地解决了科研单位项目团队的项目经费使用管理问题，彻底解决了离开财务部门，经费收支对于团队内部成为一笔糊涂账的现状与问题。

 

开发周期：熟悉EOVA + 数据库设计 + 开发： 8个小时完成。当然开发人员对于业务和数据库部分比较熟悉，这在一定程度上起了作用。

评价：对于基本信息管理非常方便。

 

从开发角度建议后期版本改进的主要问题：

（1）在可解决业务问题的前提下，尽量使用与已有前端本身的控件，比如easyui的datetimebox，numberbox，combobox等，而减少自行开发控件（eovatime之类的）的必要，后者对于维护并没有实质性贡献。我这边试了，easyui的datetimebox，numberbox，combobox都可以很好地嵌入到datagrid里面。

Eova 自定义EasyUI Form控件的原因如下：

1.EasyUI 非开源，并且需要授权，并且样式丑，迟早会被淘汰

2.EasyUI 代码是以前端开发者思维实现的，不利于Java服务端开发人员的理解。

3.EasyUI 并未提供 例如，查找框，并且很难拓展，可能是本人JS水平有限(大部分服务端开发者都专注于服务端开发，JS都一般，中不中)。

4.Eova自定义Form，一方面为了统一样式，一方面为了后续业务扩展做铺垫。

eg.在实现 Grid Cell Edit 的时候，有一个需求是根据文本内容来逆选下拉项，EasyUI 的下拉框默认是根据Value来选中下拉项的。

 

（2）数据类型的细化：数据类型绝对不止字符、数字、时间三类；数字类型包含整型和浮点型等多种，浮点型还有精读要求；这在进行数据校验时都有其用途；

这个后续可以根据实用性进行完善，目前仅提供 字符 数字 时间，常规的业务都能够支撑了，其它的类型都可以用字符串来代替然后配合正则。

之前提供了数字框，后面又删了，类型多了 维护就麻烦了 不符合通用的原则。

这个会根据用户实际使用进行调整...具体情况具体分析！

 

（3）类似于public static final String TYPE_TEXT = "文本框";这种程序写作方式，对于后期维护带来了不少麻烦。程序里面大量直接基于  == "文本框" 的判断提高了程序可读性，但不符合可扩展性的要求。加入你要将软件国际化，怎么办？既然你定义了那么多的全局变量，那就用全局变量来判断了。在数据存储时，空间类型也不该被存储为“文本框”之类的中文，同理，你面对的国际化客户可能不喜欢这种模式。

Eova的定位是国产开源软件，各种设定均正对天朝的用户习惯，暂时不考虑国际化，如果有需求的可以定制，改动也不会很大！

国际化 要变的不仅仅是 文字，各种操作，体验都需调整。

 

（4）代码还是可以进一步简化，一些模型的存在着实没有实际意义。比如User类、Role类、Btn类、RoleBtn类。既然你是基于元数据的，这些模型同样可以在Object和Field（Eova用的是Item，这个词语实际上没有实质含义）的基础上自动化。

Eova是基于OOP 然后才是基于元数据。后续扩展中 Java Bean 会起到重要作用，目前业务简单，当然没有任何作用，这就是为什么JFinal要主推 Model 然后才是 Record操作。

 

（5）目前在对象管理和字段管理方面，可做的更灵活，比如编辑框的大小可作为Object的属性之一，让用户自己管理，因为有些对象字段较少，编辑对话框可以小点；有些比较大，则可以定义得大点；字段管理，需要引入 最大字符长度、数据精读以及最大值、最小值、数据范围等check constraints。这部分check constraints与后期的数据校验密切相关。

校验目前，只提供的 最简单的两个属性，下一个版本 会强化，支持常用校验，正则，异步

 

（6）目前对于错误的捕获和解读仍然处于开发模式，使用中，如果用户看到的是各种Jfinal.activeRecord错误，那对于开发团队来说，是一种灾难。

后面会设定成可配置的，INFO DEBUG

 

（7）当元数据导入后，菜单管理默认添加查询功能，但很多时候查询是有范围限制的，比如部门经理可以查该部门人员的所有信息，部门人员只能查自己的，等等，对象的过滤表达式是否需要考虑如何开放查询范围的问题。

后续会强化表达式，以支持 环境变量 虚拟变量 等多种高级用法，以满足复杂业务的实现。

 

（9）有关Session可以开放，将Session可能涉及的变量内容开放给用户自行定义，比如Session("user")、Session（"department"）等，因为这部分内容很可能成为（5）中查询范围的输入参数。

Session V1.2 已经开放，业务拦截器里 可以获取 Controller，关于Controller的一切都可以随意操作，具体参考JFinal手册

 

（10）Master-Detail模式、Tree + Grid模式后期可以考虑。

不用考虑，一定会有，我保证，已经在计划列表了

 

总结：非常感谢念小山对Eova的支持和协助，能实际使用，并且提出这么多专业的问题，真的是棒棒嗒！值得大家膜拜！也希望大家多多提问，我一定会一一解答。不怕有问题，就怕无人问津！