ExtFrame的特点与缺点
这个架构么,特点还是很突出的,缺点么,这个......
首先,这个架构把B/S编程几乎完全变成了界面编程----前台开发人员几乎不需要写特殊的Javascript代码,基本上都是在编写诸如新增、编辑、详细信息之类的界面(全部是ExtJS的Form之类的东西),另外,还要进行一堆配置(这个缺点是比较复杂了些),分层很清晰,不会出现一个逻辑要写一大堆脚本,再写一大堆后台方法这种情况
核心脚本的结构异常清晰,不会出现一层一层的套用(可以看看树的代码是怎么写的),我痛恨那种为了实现一个业务逻辑,new 一个button,然后在click事件里来一个new Ajax.Request,然后在success方法里再来一个new Ajax.Request这种写法......
其次,这个架构是真正的完全无刷新的B/S页面,所有操作都是基于Ajax的,效率上真正不弱于C/S,当然,这也引发了可能存在的缺陷(偶还没证实),主要是效率上的,因为进入系统后要载入所有脚本,并且渲染所有界面,这个对系统的性能消耗是难以估计的(目前百来个Panel貌似没出什么问题,不知道几千个会怎么样,不过应该还是有办法弥补的)
其实最主要的特点还是基于开发上的,通用功能完全都封装好了,开发人员基本无需编写额外代码而只需要关注于界面和业务逻辑上,无论哪层,代码结构都非常简单明了
架构是基于ExtJS2.2和MVC2.0的,对于ExtJS这个最大的缺点就是收费问题了,所以没敢用更高的版本来开发,而ExtJS2的莫名其妙的BUG实在是有些讨厌
MVC架构其实也只用了所有功能中的一点:使用Controller作为Ajax的载体,相比ashx来说,这个更合适
相比Java的SSH框架,其中的Struts我这里是使用MVC的Controller,Spring的功能我这里只是自己写了个IOC的container来提供IOC对象支持,而持久层则使用的是老的代码做了些升级修改,连Linq都没用(有同事老说我不进步,我说你用Linq实现原本的功能看看)
框架最主要的封装是封装了通用的功能:增删改查,这些功能几乎都无需再额外写代码,这就是持久层提供的功能:对抽象的实体类进行处理,而不是象Hibernate那样必须定义实体的Class,原本打算用Java实现时遇到的最大困难就是在这点上:任何数据库改动,Hibernate里都需要修改类重新编译,而且没有通用的对数据的保存方法
而原本的.Net框架,只需要修改数据库后再修改下实体的配置文件就可以了
在持久层封装的异常简单,一个using (IDataProvider = DBDataProviderFactory.Create()) {}就可以获取到数据库连接,目前可以自动支持SqlServer,MySql(这个是我加的接口支持),Oracle等数据库,除了手写SQL时要考虑数据库是否支持外,其他的几乎不用管数据库是神马,而操作对象都是基于类BaseEntity的数据
不过有个缺点,原本有个实体设计器,这个设计器可以在设计完实体后直接创建到数据库,但只支持SqlServer......因为很多年没维护过了
另外,最近在维护一个旧版本网站时深刻体会到JS框架的重要性:那个网站去年好好的,今年扩大使用范围后很多用户反馈出现问题,基本上都是浏览器兼容性造成的,很多用户使用360神马的浏览器,赶快通知一律使用IE,结果原本测试时IE8是没有问题的,很多用户还是出了问题,有的点兼容性视图能解决,有的根本解决不了,又改用FF,差点没把我折腾死。用ExtJS这样的框架,出现兼容性问题的可能性应当会小许多(当然还是需要测试才行)
架构里最突出的封装么,主要是Grid、树、工作流等组件了,缺点么,这些东西封装的基本只有开发人员能配置了,用户无法自己进行设置
这个架构最适合的么,大概是OA之类的开发了,基本都是些增删改查之类的操作,几乎不用编写代码(其实目前就是在拿着做一个OA项目)
不过其他的业务系统也可以使用,主要是要集成到ExtJS的Window里
这个框架目前最大的不稳定性似乎是在持久层上,有点很郁闷的说,找不出问题在哪里,主要是进行调试时,第一次进入后经常会出现数据库连接错误,其实部分数据都读出来了,但是在运行中,会出现ADO层在进行了DataSet.Fill操作后,DataSet.Table[0]居然没有的情况,然后继续运行会出现读取一张权限表时数据库连接产生致命错误,继续运行错误消失了,但是SQL执行结果很奇怪,有时执行相同查询,前面2次数据不正确(读出来的数据莫名其妙的结果,连字段都不对),第3次正确,一换模块,又出现2次不正确第3次正确,遇到这种情况,关闭调试环境的IIS,重启调试,多半就好了(也不是每次都必然会出现这个现象),我推测和使用的.Net Cache机制是否有关系,因为我把数据库连接缓存到Cache里来保证离散的业务逻辑使用的是同一个数据库连接(保证是同一个事务),我把这个框架给开发人员,似乎证实使用火狐出现问题的几率比IE高......