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高......