前端开发大部分时候面对两类问题：一是业务逻辑，二是界面展示逻辑。在一个管理系统或互联网产品中，我们首先会通过业务数据对整个业务系统建模。所谓业务逻辑，反映到程序层面就是对一些业务数据的增删改查操作；同时我们也需要将这些业务逻辑的操作结果反馈给用户，这就是界面展示逻辑。比如当你在发布一条微博，在业务逻辑上是多了一条微博数据，同时在界面上也需要将这条数据呈现出来。在我看来，用户界面本质上就是业务数据的一种对用户友好的展示形态。一个理想的前端架构是将业务逻辑和界面展示逻辑完全分离，两者独立变化，互不影响。在我们考虑业务逻辑的时候，就不要考虑界面展示的问题；在考虑界面展示问题的时候，就不要考虑业务逻辑的问题。如果将两者耦合在一起，那么在面对复杂问题的时候可能就会左右为难，无从下手。
MVC模式的主要目的就是将业务逻辑和界面展示分离。虽然对于C(Controller)是有争议的，但是M(model)和V(view)是普遍认同的。将业务逻辑和界面展示分离的关键也在model和view的分离。angular是一个非常优秀的MV*框架，非常好的体现了MVC的思想，本文将从该角度来介绍angular的一些使用心得。
需求
这是一个后来管理页面，用来设置各个客户端的banner显示。页面主要有以下功能：
1.编辑banner信息，可以设置banner的类型和上传banner图片。
2.删除和插入。
3.上下移动banner顺序。
4.保存。
实现业务逻辑
不考虑页面展示，我们可以先实现业务逻辑。各个端banner列表的逻辑是一样的，只是类型以及与后台的交互接口不一样。我们可以将banner的这些列表逻辑定义成一个service，不同端的列表都可以重用这个service。其定义如下。
这个service的实现非常简单，就是对一个banner数组进行增删改查。
实现界面展示逻辑
实现完业务逻辑我们再来解决界面展示的问题。angular提供了一个非常强大的模版引擎,通过指令和表达式就能将数据呈现到界面。如何才能模版中使用这些业务数据和方法呢？我们需要将这些数据和方法写到scope对象中,scope对象定义了对应模版能够使用的数据和方法。bannerCollection service的attach(scope)方法就是将对应的banner数据和方法写到scope对象中以便能在模版中使用。下面的代码是在mobile controller中使用bannerCollection service,并通过其attach方法和对应的scope对象绑定。
将数据和方法注册到scope对象后，我们就可以在模版中使用了。下图是模版的一部分。
ng-repeat指令用来展示banner列表，双花括号用来输出数据，ng-click用来响应用点击。angular框架提供了许多非常有用的内建指令，基本上能满足我们大部分的需求了。除了内建指令，angular还为我们提供了自定义指令的接口，通过自定义指令我们可以扩展出非常丰富的web组件。在这个banner管理页面中，有个上传banner图片的功能，我们就可以将其封装成一个指令。
如上图，该指令的实现主要在link方法中。每个自定义指令都可以实现这个方法，当模版引擎在链接模版的时候会回调指令的link方法，调用时将当前的scope和element作为参数传进来。link方法非常重要,它体现了指令的本质：scope到element之间的一个桥梁，其实也就是model到view的一个桥梁。我们可以在这个link方法中监听element的事件来响应用户操作并修改scope中的数据；也可以监听scope中数据的变化将其反映到用户界面上。scope对象有个$watch方法，可以通过该方法去监听scope中需要关心的数据的变化。
在这个图片上传的指令中，我们在link方法中监听了用户选择文件的事件。当用户选择文件后，通过post请求将图片上传到后台生成url和dsfid，同时更新scope中的img数据；ng-repeat指令在监听到scope中img数据的变化后又会刷新相应的界面展示。
结语
angular为我们提供了一个非常好的业务逻辑和界面展示逻辑分离的机制，极大地简化了前端开发。特别对于数据型应用，angular是非常好的选择。
