之前的开发框架问题汇总

已经解决的问题

1. 组件化结构

2. • 开发相对简单
   • form,list,tree等组件，基本上能够满足页面制作的需要
   • 通过直接向组件中写html，也能实现复杂的页面。
        

3. 快速生成

4. • wide支持
     

5. 多语言

6. • 简单支持，通过properties文件设置
     

7. 结合操作权限

8. • 实现了操作权限，能够做到按钮级的权限控制
     

9. 结合xresource

10. • 实现处理下拉、联动、属性替换等功能

11. Page自动注入

12. • 自动完成BO等Bean的注入工作，节省了配置

13. 结合webx

14. • 能够方便的使用到webx的所有功能

15. 简化的Dao

16. • 不再需要写一堆的Dao接口+实现了，属于shy之外的封装
      

存在的一些的问题

1. 组件模式，是否适合开发

2. • 数据绑定组件，组件组成页面，会不会方便大家页面的开发。
     
   • 希望组件重用，但重用的机会并不大，并且重用的时候也并不方便
   • • 首先，组件重用，主要表现在wide开发的时候。但重用的地方，通常需要对组件进行修改，往往这些修改都比较大，重用的机会就相应的变小了。这是一个双面的问题，首先要看页面重用的意义在哪里？什么时候需要重用？
     • 另外，如果是查询页面的增、删、改、查、详情之间的切换，是可以用一个页面完成。并且此类功能以后完全可以让系统自动生成。
       
   • 能不能提高开发效率？
   • • 使用者的体会，是加速还是造成了瓶颈
     • 问题是什么？是由于框架自身的缺陷，还是由于封装的不足？
       
   • 其他的缺点
     

3. 组件未支持的功能

4. • 组件不支持的特殊功能怎么处理？
   • • 组件升级，render升级
     • 直接在程序中向组件写入html，目前我们的程序中有少部分这样的代码
     • 总的来说是不怎么方便，开发的时候需要了解组件目前所支持的情况，然后看应用的需求如何能用已有的功能实现。
   • 不支持ajax
   • • 理论上可以开发支持ajax的组件，但目前还未有实践
       

5. 扩展性

6. • 希望组件能够很容易的扩展，并灵活组装
   • • 目前明显支持的不够好，虽然可以通过成对的增加组件和render的方式来扩展，但由于在框架中存在一部分硬编码的方式，导致增加组件后，需要修改一点框架代码。
     • 结构上的设计缺陷
       

7. page问题

   • 结构不够合理
   • • 比如页面的继承，用起来并不方便，导致页面的重用机会不多
   • • page，组件，field等的接口有很多地方不够合理，需要改进
       
   • 生成的Base类和集成类中有很多冗余代码
   • • 页面属性的设置时代码过于罗嗦（一个个属性加入是否好一点），页面变化多的时候，每个地方都要写很多代码。当页面很多属性的时候，变的很恐怖。

8. render实现的问题

9. • 基本上是乱七八糟，并存在很多不再使用的代码，导致修改的时候会引起其他意向不到的问题
   • • 前期已经做了少部分改进
     • 需要完善或者重写
       

10. DateObject的问题

11. • 基于Map实现的方式,有没有必要用标准的JavaBean替换
    • • 装载省事，如果改为JavaBean，只要这个地方修改即可
      • 可以传递一些自定义的属性，改为javaBean后，可能需要特殊的实现来处理这种需求
      • 存的数据都是String导致很多的转换，即使目前做了修改，从页面上进来的时候还是String，只是从db出来 的时候是对象、在get出去的时候做了判断并转换
    • DataObject一直应用到了Dao层
    • • 这种做法是否合理，页面上的数据，部分不需要提交到dao，不过按目前的dao实现，就算提交过去也没什么影响
      • 是否需要页面数据对象和Dao的数据对象分离，分离后就要做数据映射、复制或者赋值，麻烦
        

12. wide缺陷

13. • wide存在比较多bug，使用中要比较小心，希望以后页面相关的操作，更多的能在wide中完成

    • 功能不够完善
    • • 缺少从db直接生成的功能，开发中，很多时候还是会先把表建好，从db直接生成，开发效率会更好一些
      • 汉化的工作能够直接完成，避免去修改多个地方,db的注释能够直接使用到页面上，避免重复工作
      • 页面跳转等设置也能够直接完成
      • 对象属性的修改能够直接体现到组件上，缺少该功能很别扭
    • 能够和应用独立开，不要发布到一起
    • 存贮的信息能够写入db，或者hsql之类的内存db中，并可以方便切换，更好的支持团队开发
    • 制定明确的页面模板规范，统一页面风格
      

14. 页面静态label的国际化方式

15. • 并非真正的国际化支持，只是根据服务器的语言选择，没实际意义
    1. • 放到xresource中或者采用其他的多语言方式，更好的和wide接合，减少重复工作
         

16. 缺少数据权限的处理

17. • 权限框架支持数据权限，可能通过修改来支持，但细节问题需要权衡，比如如何接合，如何授权等等
      

18. 项目搭建

19. • 整体项目的搭建模板
      

框架改进的两个方向

    从技术角度去升级框架，从应用角度去封装框架

1. 重构

• • 探索更好的开发框架

2. core调整,wide加强

3. • 调整目前发现的不足之处
   • • core只提供框架相关的组装接口，带来更好的扩展性
       
     • 支持组件以及render的简单接入
     • 动态支持组件和render的绑定，给开发者更多选择，从而减少因特殊功能的要求而不得不修改core的次数。
       
   • 修改render实现不好的地方
   • wide加强，能够支持更快的开发模式
   • • 比如从db直接创建应用，建立标准的增、删、改、查模型等等
     • 或者能够直接生成DB相关的表，类似mda的思想，能一条线下去做好所有的事情。
     • 按优先级、难易程度排序
       

4. 模块化应用

5. • 通用模块
   • • crm的每个子系统可以通用的模块，能够方便的跟随子系统一起发布，如审批，用户、权限等后台管理模块
   • 公共模块
   • • 系统可以共用的、并且只要作为一个系统发布的模块。这些模块，能够为所有的子系统提供服务，并且不用跟随每个系统发布，通常和业务相关性不强，如果能够很好的独立出来，作为一个独立模块维护发布，其他的应用就更单纯一些。
     • 进而将不同技术实现的应用都挂在同一个portal下，已有的应用和将要开发的应用可以通过某种策略实现整合，从而可以将已有的应用一点一点的重购过来，为开发框架统一做准备