浅析angular js
这两天又把angular翻阅了一遍,感叹一下现在应用的发展越来越向前端靠拢,前端的代码越来越复杂,我们确实需要一个前端的框架,我们更需要优秀的前端架构师。如果还有人象3年前一样鄙视前端开发工程师,那么他们将会被淘汰。另外,原先我们所谓的前端工程师大家理解成就是简单切个图,套套页面,但如果真这样理解,这又out了。后面会有更多有程序基础,有架构经验的大拿逐步往前端冲。会把这些仅仅会切图的人员冲掉,这是趋势。跑远了跑远了,angular就是一个优秀的webmvc框架,模板,数据,视图。
他的概念是页面上是由一个一个的“app”组成,我们可理解每一个网页,都是一个“桌面”,而“桌面”上是由多个拼凑的“应用”象搭积木一样,搭建而成。
好,这就是由页面引入到应用,而应用,既然是应用,就尤其结构。首先每个应用的展现就直接绑定到页面都某个标签下,比如div。而div的所有内容,就是这个应用v。而control,当然是在外部引用js做到的,他们用的是显示声明congtrol入口注入函数的方式实现,这样,更容易的让congtrol进行模块化的开发。而M是一个数据模型结构,直接通过ajax的方式和后端绑定,而同时通过底层替换,又和前端绑定。不错的设计!而这个webMVC模型最精彩的地方在于,对模型的控制相当好!尤其是在V端事件上和M的绑定,完全做到双向数据刷新,这个我是觉得很佩服的,估计也是大家觉得angular非常不错的一个地方吧,只要你绑定了,模型自动穿透从V到C端,然后和后端直接交互。
但,从技术框架的角度上讲,有几个薄弱的地方,首先一个死穴,这种前端模板形式,如果拿去做搜索seo关键词优化,会死的很惨,具体我不说了。当然,这是百度,googe这种搜索大户技术没跟上导致的,但没办法,人家是大爷,不过好在,PC时代逐步过期,移动时代可以大胆的不管这个问题,比如我们敬爱的微信开发就如此。其次,这个MVC架构中的“V”部分的实现方案亮点有了,就是自动绑定M,但是问题也是有几个,第一个直接把视图内容放到页面,由C初始化后实现绑定,这个方案是值得商榷的。我们乍看是让编程更简单了,但用这种方式是个hello感觉很好,但一个复杂的页面就不是这样了,一个复杂页面6七八百行,上千个标签,让人使用了,就是会有一种作死的节奏,作为有经验的程序员都知道,一个程序的生命周期,只有10%是在开发阶段,90%是维护阶段。所以别小看一些简单的代码规范和一些小的非技术性的整理优化,效果不是一般的大。我觉的更好的做法,是既然是独立的应用,应用的视图也应该抽离出去,独立成完整组件,而主页面,就仅仅是引用应用而已。当然,实际不会那么简单,不过我自己做的一套BreezeJs的框架,两年了,经历过把组件从页面移走变成独立组件的过程,使用项目和血的教训走出来,感觉到什么更合理。另外一个就是既然是V他必然在一个应用中有多个,而多个V到底用哪个,这个应该由C很方便的控制。当然angular也提供模板的功能,但看起来总是怪怪的,并不象hello那样得心应手了。这也是很多人跟我反馈,angular入门简单,但精通困难的原因。因为一个大型的网站,使用的可不仅仅是hello world的简单API,要保证其灵活性,就要翻出很多可能不是“很友好‘的底牌了。
我在10年参与过华为的UXE项目,这也是一个webmvc框架,当时angular还没出来,Google有的是一个gadget的概念。我们参考了,并吸收了安卓开发的一些思路,定下的方案,至少,当时的思路跟这个是非常象的。但我始终在思考一个问题,web前端的发展,和之前技术发展是不一样的,当年的技术发展,是因为后端经过将近20年的技术积累,大量优秀的架构师的沉淀,这些都是前端可以用的,所以对于一个前端框架,一个优秀的前端框架,只要尽量的把后端的优秀实践往前搬就好了。基于这个想法,我在UXE的基础上,实现了属于我自己的BreezeJS。我觉得对于前端的框架一定要具备几点,当然我也是按照这个原则去设计的:
1.基于MVC的分离,这个基本合格项,如果连这个都没有直接枪毙
2.模块化,我很推崇java的(当然我自己是java将近20年的拥趸),一个类做一个事情,一个事情就一个模块。不用自己写,seajs就很好用,大家有兴趣自己查吧,玉伯,淘宝的顶尖大牛,不是盖的,还是要感谢他再次的分享。
3.封装的尽量薄。这句话其实说的不准确,其实就是说,要尽量的减少规则!上面也分析过,任何一个框架,在实际大型项目使用时,都不会想教程或者helloworld那样的美好。就像美女一样,照片很美好,现实很残酷。越薄的封装,能让其扩展性更强,而这个扩展性是和原生态对接的,使得扩展的成本更低(学习成本)
4.尽量模拟后端概念。这个很好理解,我觉得还是之前的那个原则,后端经过架构师们20多年的沉淀,所谓面向对象,所谓的继承,所谓的类,都是有他们的道理的,所有的设计模式,都是现成的,稳定的,经过检验的,所以尽量”搬过来“。还记得农夫山泉那句广告词吗”我们只做大自然的搬运工“,就是这个概念。
5.简单,简单再简单。成本考虑啊,我举个例子,你整个框架要月薪10k的人才能驾驭而且招聘还很难,我整个框架月薪3k的人就能上手,而且市面一把。你会选哪个?有时现实就是很丑陋,什么设计之美之类的,在实际的公司成本运作下,都要靠边站!
我们的BreezeJs,也是一个webMVC框架,在众联breeze上,有兴趣的大家可以上去翻翻,如果我说的这几点有点道理,也可以上去对比一下。
另外,BreeezeCms是一个管理台模型,其中的展示部分,就是用BreezeJs做的,写的还不错,有兴趣的读读,用的是设计模式中经典的decorator模式做的,所以代码的类名中很多xxx decorator,当然BreeezeCms前后端都有很多内容,这里大家主要关注一下他前端的实现吧。核心的逻辑代码在gadget下面。
最后angular是非常不错的一个前端MVC,Breeze框架也有后端和前端,我尝试着用我们的后端技术就是BreezeJava和angular进行配套,整合还不错,挺有意思的。其实很简单,就是对ajax发送做了一个很浅的封装,代码如下:
程序代码:
var $breeze = function($http){ return { server : "breeze.brz", doServer : function(name,package,param,callback){ //配置好参数 var postParam =[{ "name":name, "package":package, param:param }] $http.post('./breeze.brz', postParam).success(function(response,a,b,c,d,e){ if (!response || response.length != 1){ callback(1001,"结果数据不正确"); return; } callback(response[0].code,response[0].data); }).error(function(data, status, headers, config) { callback(1000,status); }) } } }
我把这段代码放到angularbreeze.js中了,调用方法很简单:
程序代码:
<!DOCTYPE html> <html> <head> <meta charset="utf-8"> <title></title> </head> <body> <div ng-app="myApp" ng-controller="customersCtrl"> <ul> <li ng-repeat="x in names"> {{ x.name + ', ' + x.m2text }} </li> </ul> </div> <script src="/a/breeze/lib/js/jquery.js"></script> <script src="/a/breeze/lib/js/angular.min.js"></script> <script src="/a/breeze/framework/angular/angularbreeze.js"></script> <script> var app = angular.module('myApp', []); app.controller('customersCtrl', function($scope, $http) { $breeze($http).doServer("queryMod2","test","",function(code,data){ $scope.names = data; }); }); </script> </body> </html>
搞定。要说这样做的好处是有的,BreezeJava通过service为访问入口点,用自动机驱动组件,基本不用写代码,可以搞定后端逻辑。如果是只关注前端的童鞋,这个东西帮助是很大的。
声明,文章转载:http://bbs.