`
wwwlgy
  • 浏览: 7891 次
社区版块
存档分类
最新评论

浅析angule

 
阅读更多

这两天又把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框架，在http://breeze.joinlinking.com上，有兴趣的大家可以上去翻翻，如果我说的这几点有点道理，也可以上去对比一下。

另外，BreeezeCms是一个管理台模型，其中的展示部分，就是用BreezeJs做的，写的还不错，有兴趣的读读，用的是设计模式中经典的decorator模式做的，所以代码的类名中很多xxxdecorator，当然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为访问入口点，用自动机驱动组件，基本不用写代码，可以搞定后端逻辑。如果是只关注前端的童鞋，这个东西帮助是很大的。

好了附件再把angularbreeze.js附上。

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

分享到：
| Autodesk和SanDisk的开源战略总监谈开源
评论
发表评论

您还没有登录,请您登录后再发表评论

相关推荐

Magicbox
Global site tag (gtag.js) - Google Analytics