EasyOPOA and BackboneJS comparison

EasyOPOA和BackboneJS在OPOA系统构建时的比较

BackBoneJS也是一个进行OPOA程序设计的有利技术。使用EasyOPOA和BackBoneJS都可以完成OPOA程序的设计。

从设计角度： EasyOPOA是一个纯粹的OPOA程序构建框架；而BackboneJS本质是一个前端JS的MVC框架，而非OPOA框架。

从技术角度： EasyOPOA侧重于为构建OPOA系统；而BackBoneJS侧重于利用前端MVC构建系统中的某个模块。

• BackboneJS：

侧重提供一个JavaScript端的MVC引擎框架。服务器端仅给出模型数据，客户端所有的业务控制、视图渲染和更新都靠客户端BackboneJS用MVC组件完成，系统实现完全依仗于JS编程能力。

优点：

• BackboneJS是从服务器端返回模型数据，不带视图，在客户端通过JS完成渲染，这样，使用BackboneJS能够减少服务器端设计，仅在服务器端输出模型数据即可，通过客户端MVC来控制代码，在客户端渲染视图，减少流量，提供更好性能。

不足：

• 加重了前端开发难度，需要专业前端人员，并同时要求开发人员必须有较高的JavaScript系统设计水平

• 不利于搜索引擎优化，无法从服务器抓取有意义信息

• 不适合业务、模块、视图种类复杂多变的OPOA程序构建，随OPOA程序复杂性提升开发难度也上升

• EasyOPOA：

EasyOPOA为OPOA程序设计提供了引擎和实现。更侧重于服务器端MVC，以Easy为目标，让后端开发人员无需学习前端MVC引擎和实现规范，尽可能的降低了前端的开发使用难度。

优点：

• EasyOPOA更多侧重于服务器端MVC技术，减少学习开发的成本和难度，仅需掌握EasyOPOA有限的几个API即可

• 解决了搜索引擎爬取问题，利用RSP设计，能够有针对性进行搜索引擎优化

• 能利用自身掌握的服务器端技术解决问题而非依仗高超的JS编程能力，降低OPOA开发难度

• OPOA业务、模块、视图种类的复杂性并不会增加构建的复杂性和难度的增加，技术难度是水平的不会增长

• 抽象规范和简单，即使您是个JS和OPOA的新手，也能构建出一致、可靠、稳健的程序

不足：

• 由于视图是依靠服务器端渲染和返回，所以传输流量略大于BackboneJS。（EasyOPOA是直接从服务器端获得渲染页面（即视图结果）；而BackboneJS是从服务器端获得数据在客户端渲染视图）

• 设计理念和目标的差异对比

可以说EasyOPOA的设计初衷就是为了解决OPOA程序的复杂性问题，将OPOA抽丝剥茧，化繁为简，为复杂业务提供框架支持，降低开发编程设计难度，让开发人员更容易开发。即使你是一个JS的新手，在EasyOPOA框架帮助下也能迅速开发出稳健、高质量的OPOA程序。符合其More Easy， More Powerful的理念。

EasyOPOA秉持了对业务友好，对开发人员友好的特点。而反观Backbone，从业务和开发人员学习角度来讲，略显陡峭，而且掌握其MVC组件并不等同于能设计复杂OPOA系统，开发质量取决于开发人员的水平。

学习BackboneJS对传统开发人员来说学习曲线较高，需要有较强的JS功底，同时需要理解前端MVC的特点和不同，主要是掌握BackboneJS中为MVC开发定义的各个模块的规范、作用和定义方法，以及配套的数量庞大的前端API。而最终的程序质量还与个人对前端程序的理解、系统的设计，以及JS编程应用水平有关。

• 总结和建议

两者从设计理念和实现目标上并不相同，决定了两者并不存在完全的替代关系，也并非水火不容。

相反，两者配合使用也许更能让OPOA程序变得强大，在设计时可以使用EasyOPOA进行系统全局的构建和控制，作为大项目的OPOA驱动引擎；而BackboneJS复杂完成系统中局部模块的功能，发挥前端MVC的优点和魅力。

结束

如果您有更好意见，建议或想法，请联系我。