AngularJS + controller + 总结

上午终于上线了之前两个礼拜做的需求，过程中遇到了挺多坑的，还夹着一个偏前端端别的项目在做，有点紧张。在AngularJS做的那个项目中，性能上问题是个大问题，想了下，除了ui-grid这个控件可能不太适合我们那个项目（因为项目要有编辑表格的功能，逻辑还挺繁复），最最重要的是：什么都写在controller里面，成了代码的瓶颈，directive反而特别轻，没能做到分开来，没能做到该做什么的就去做什么。还有就是没有组件化，重复的代码太多。这个是我自己的问题。等空下来了，要重新组织下代码，面向对象进行重新设计，而且代码规范，格式什么的，要做调整，让后面接手的能也能很快很好的看懂自己的代码。

因为用的是AngularJS，angularJS的事件机制关注了很多scope，从某个角度看，事件本身就是发布订阅模式。angularJS的事件机制对性能等影响也是有关系的，不过也看怎么用。

总之，这次是陷在业务里面了，但是跳出业务来看，还是要提高抽象度！！！这样花费的时间才更有意义，也不能说用的框架比较老呀什么的，关键还是用现有的技术，深入去理解这个技术，更好的去解决业务上的痛点。

谈到框架，很多大神都说框架这个东西，是解决一些特定场景的问题的，不需要太过于纠结，要有思辨能力。慕课网上看到一个视频，阿里云的晨末就说“一次性的需求，见招拆招，具体问题具体分析”，需求——分析场景——抽象。

那个视频讲的是问道，挺有深度的，有思考，有大量业务下的总结，说到了很多我现在项目上的痛点，现在对那个视频做下总结:

计算器（不同选项，计算公式也会变，表单也会变

• 场景
• 组件复用

产品最了解业务逻辑

1. 支持自定义拓展
2. PD自行维护
3. 做需求背后的实现，而不是盯着需求

一个产品的组成
1. 模块 2. 页面 3. 组件 4. 功能点

组件：（组件的模型化）（UI——静态——外观，行为；业务——动态——外观，行为，特定业务场景的功能）

业务组件：angular中是个directive
变动的点做成通用数据结构，让开发者可以配置

把很多东西变成可配置项的时候，就具备了快速开发的能力（从公共组件库饮出来，配置业务模型，就可以了）

业务模块的按需加载

指令都是摆设

关于controller：

（controller本身的原罪在于它自身的角色，它天生就是界面和逻辑数据结构的桥梁，所以它和两边都耦合）

1. 父controller具备并且提供基础服务的能力（千万不要写业务代码）
2. 子controller剥离业务逻辑，只负责交互行为

工厂模式：
抽象出数据类型：{text: type: class: handler: render:}

HTML toolbar generator

1. 根据type得到generator
2. generator实例化
3. 调用generator的rendered方法

依赖注入

依赖自治（不再依赖于所在的controller）：去中心化，解放controller

框架——解决某些场景下的问题

JS基础一定要好，这样什么框架的代码都能看懂，明白框架的特性，是解决什么问题。

售卖框架（云服务器售卖）：

使用抽象化的数据结构

• 描述清楚（自然语言）一个事物
• 考虑到事物发展的规律
• 对修改封闭，对扩展开放
• 最后做到高内聚，低耦合
• 提供给开发者一个简单易懂的编程模型

约束关系：PD定的

开发者用数据结构描述页面
框架做约束解析

原则：
职责单一
开放封闭
依赖倒转
最少知识
接口隔离

比较校验器（定义一个compare指令）

angularJS的几个Tips：

• $scope 以元素属性的形式被绑定在对应的HTML标签上

  angular.element($0).scope();

  modules are containers

  Two way data-binding 脏值检测，振荡／循环依赖

  指令（嵌套，处理HTML元素，交互） angularJS封装UI组件的基础

  ng内置了jqueryLite

  i18n 国际化

  同步异步操作要分清楚