之前的开发框架问题汇总

原创 2007年09月18日 11:44:00

已经解决的问题

  1. 组件化结构

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

    • wide支持
  3. 多语言

    • 简单支持,通过properties文件设置
  4. 结合操作权限

    • 实现了操作权限,能够做到按钮级的权限控制
  5. 结合xresource

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

  6. Page自动注入

    • 自动完成BO等Bean的注入工作,节省了配置
  7. 结合webx

    • 能够方便的使用到webx的所有功能
  8. 简化的Dao

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

存在的一些的问题

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

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

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

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

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

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

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

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

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

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

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

    • 整体项目的搭建模板

框架改进的两个方向

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

  1. 重构

    • 探索更好的开发框架
  1. core调整,wide加强

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

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


 
版权声明:本文为博主原创文章,未经博主允许不得转载。

相关文章推荐

kphp开源框架分享:网站开发之前台css浏览器兼容方法!

什么是浏览器兼容:下面就由kphp框架来告诉大家,当我们使用不同的浏览器(Firefox IE9 google)访问同一个网站,或者页面的时候,会出现一些不兼容的问题,有的显示出来正常,有的显示出来不...

补充之前中兴校招面试的问题(软件开发岗位)

补充一下之前中兴面试的时候的几个问题,再不不上来就要忘光了: 1、静态变量和全局变量的区别是什么?2、写一个在单链表尾部插入一个节点的函数。 这个题目面试的时候写完了觉得自己很自信,觉得写的很好,...

Hinton Neural Networks课程笔记2a:三种主要的神经网络框架之前向网络、循环神经网络和对称网络

这一节主要是介绍了三种主要的神经网络模型:前向网络、循环神经网络和对称网络前向网络 Feed-forward Neural Networks如果把神经元看做节点,把神经元的输出到另一个神经元的输入看做...

Spring学习之旅(九) 综合利用之前的框架完成主页

完成小项目的主页
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:深度学习:神经网络中的前向传播和反向传播算法推导
举报原因:
原因补充:

(最多只允许输入30个字)