基于AngularJS的软件前端架构.docx

基于AngularJS的软件前端架构.docx

《基于AngularJS的软件前端架构.docx》由会员分享，可在线阅读，更多相关《基于AngularJS的软件前端架构.docx（11页珍藏版）》请在冰豆网上搜索。

基于AngularJS的软件前端架构

作者：

ZHANGJIAN

仅供个人学习，勿做商业用途

企业应用前端的特点

作者 徐飞 

这篇是我参加QCon北京2014的演讲内容：

提纲：

企业应用在软件行业中占有很大的比重，而这类软件多数现在也都采用B/S的模式开发，在这个日新月异的时代，它们的前端开发技术找到了什么改进点呢？

B/S企业软件前端开发模式大体上与桌面软件类似，都是偏重量级的，在前端可能会有较多的业务逻辑，这些业务逻辑如何被合理模块化，与界面分离，以便测试，成为这个领域的一个重要挑战。

另一方面，由于企业应用的界面相对规整，偏重的是数据存取，没有太多花哨的东西，所以常见的界面控件也是可枚举的，如何让开发界面的工作能更快完成，甚至由不擅长编写代码的业务设计人员来做，与界面原型的工作合二为一，能提高不少开发效率。

在AngularJS等MV*框架出现之后，给这个领域带来一些契机，架构师们能够有机会去重新规划前端的架构，甚至是开发流程，从而让整个软件的生产更为高效。

本文将探讨它给这个领域带来的变化。

正文：

企业应用系统是一种很常见的软件系统，这类系统的特点是面向某个行业，功能较复杂，对界面的要求一般是整齐，不追求花哨。

这类系统通常有C/S和B/S两个流派，其中的B/S方式因为部署和集成的便利，使用得较为普遍。

同样是在浏览器中做东西，写企业应用和网站的差别也很明显。

企业应用的业务逻辑较重，前端有一定的厚重性，但是对效果并不追求很多，主要是各类控件的使用，表单的存取值等等。

企业应用产品的一些特点如下：

∙独占模式——一般用户使用互联网产品，都是片段时间使用，比如购物或者阅读，做完之后就刷新或者关闭浏览器了，而企业应用往往是工作的全部，从早上上班开始打开，到下班才关掉，一天绝大部分工作都在上面完成，比如一个呼叫中心的操作员。

∙重业务，轻视觉——企业应用对视觉的追求是比较低的，一般不会要求花哨效果，以业务操作的流畅性为第一目标。

∙界面规整，单一模式——企业应用的界面布局相对有模式可循，可以用很少的场景来穷举，界面横平竖直，比较规整，使用到的控件元素也是可穷举的，基本没有什么特效。

∙键盘操作——由于企业应用的用户都相对比较专业，在上岗之前需要经过统一培训，而且每个用户使用的频度较高，很多时候他们会用尽量快捷的方式来做操作，比如键盘，这一点在互联网产品中比较少见。

所以，有时候大家为了追求好看，把系统原生的select用div来替换，在这种情况下反而增加了用户的麻烦。

∙逻辑复杂——我之前所在的行业中，业务逻辑很复杂，前端可能会需要写很多复杂的逻辑，JS代码大部分是在处理逻辑，而不是界面交互。

∙加载速度的侧重不同——互联网产品往往很重视首屏优化，但是其策略可能与企业应用不同。

比如说，3个200k的模块，在网站型产品中可能优化成一个100k加三个150k的模块，但在企业应用中，很可能优化成一个400k加三个50k的模块。

为什么会这样呢？

因为内容型的网站讲究的优化策略是分摊，如果首次加载太慢，会很影响用户的信心，但企业应用用户的容忍度是较高的，他并不在乎刚打开的时候慢一些，因为打开了之后就要用一天，对于之后每步操作的模块加载速度倒是要求很高。

另外，对于内存泄露的处理，也要求得比较高一些。

整个这些策略，其实是来源于C/S系统的影响。

∙浏览器版本相对宽松——很多时候提到企业应用，大家的想法就是低端，IE6，但其实这个的原因是客户只购买软件，运维一般自己做，每年不会有很多持续的投入来改进，所以导致很多老系统不能持续升级。

软件厂商其实反倒可以用更激进的策略去升级浏览器，用户对这个的接受度还是比较高的，使用系统的群体也是比互联网用户小很多的，抛弃老旧浏览器的事情也确实可以干，比如我就见过几年前某电信营业系统预装的都是Firefox。

企业应用常见的前端框架

在开发B/S企业应用前端的人群中，有很大一部分群体选择了服务端的组件化方式，比如JSF之类，它的弊端是与异构服务端的第三方系统集成比较麻烦。

也有不少人使用Bindows和ExtJS这样的框架，最近的KendoUI也是个不错的选择。

每种类型选一个有代表性的来说说：

∙HTC在浏览器端扩展标签——早期有些团队采用的方式，一般会跟XMLHTTP等结合使用，易于使用，界面代码整洁，但已被主流浏览器抛弃。

∙JSF等在服务端生成界面——以后端为主的架构师最推崇的方式，受Struts的MVC模型影响很深，弱化了前端，使得前端蜕化为后端的一种附属。

∙GWT编译阶段生成界面——写其他语言来生成HTML和JS，一般会依赖于一种前端UI库。

这种方式也比较受后端架构师喜欢，因为他们觉得写JS很头疼，宁可写Java。

∙ExtJS用JS封装界面组件，干脆就不要HTML了——这是另外一种极端，从Bindows开始，使用纯逻辑代码来描述界面，走着跟JavaSwing一样的道路，也有不少人喜欢。

但这种方式在没有好用的界面设计器的情况下非常痛苦。

∙Flex等脱离HTML体系，另辟蹊径——这条路其实是对JavaApplet的一种延续，好处是可以不受HTML体系的制约，独立发展，所以其实这些体系在企业应用领域的成熟度远超HTML体系。

曾经的企业B/S应用几件宝

有一段时间，我们几乎只有IE6，所以那个时候的前端开发人员很快乐，没有兼容的压力。

那时候，我们如何构建前端应用呢？

参见这里的分享。

∙HTC——这是最好用的声明控件的方式。

∙XMLHTTP——尽管还没有AJAX的概念，但我们已经可以用它做前后端分离的传输机制了。

∙VML——在IE里面画矢量图，不使用插件，有其他选择吗？

∙XSLT——把XML数据转换成HTML，跟现在的前端模板像吗？

∙popup——创建右键菜单最好的方式。

具体实例请参考用这些技术构建的一个典型企业应用。

单页应用和前端分层

当时这些系统的构建方式也可以算单页应用，我们用iframe来集成菜单，每个菜单有自己独立的功能，整个主界面是始终不会刷新的。

时光飞逝，这些年，前端有了什么本质的改变，产生了翻天覆地的变化吗？

有时候我们回顾一下，却发现多数都是在增加完善一些细节，真正有颠覆性的有比如以RequireJS和SeaJS为代表的模块定义和加载库，npm这样的包管理器，grunt，gulp，XXfis这样的集成开发模式。

为什么它们算是本质改进呢？

因为这些标志着前端开发从粗放的模式，逐渐变化到精确控制的形态。

比如我们再也不能不管代码的依赖关系，也不能一打开界面就不分青红皂白把所有可能要用到的代码都立刻加载过来，那个时代已经过去了，从任何角度讲，现代的前端开发都在精细化，从代码的可控，到界面体验的精细优化，到整个团队甚至公司甚至互联网上的组件共享，以及前端团队协作流程的改进，这已经是一个很成规模的产业了。

我们把眼光放到2013年，在这一年里最火的前端技术莫过于NodeJS和AngularJS，前者给我们带来的是一种开发方式的改变，后者是一种典型的前端分层方案。

Angular是前端MV*框架的一个流派，用过的人都会觉得很爽。

它爽在什么地方呢？

因为它帮我们做的事情太多了，一个双向绑定，无所不包，凡是存取值相关的操作，基本都不用自己写代码。

在企业应用前端功能里，表单的存取值和校验占据了很大的比例，这些事都不用干了，那简直太好了。

如果就因为这个用Angular，那还有些早。

有一些第三方代码被称为库，另外一些称为框架，Angular是框架而不是库。

框架的含义是，有更强的约束性，并非作为辅助功能来提供的。

先看一下企业应用的通常形态吧，会有一个可配置的菜单，然后多半会采用MDI的形式，能打开多个业务功能，用选项卡的形式展示起来，可以随时切换操作。

每个人每天常用的功能是可以穷举的，他进入系统之后，一般要用到下班才关掉。

所以这种系统非常适合做成单页应用，开始的时候加载一个总体框架，每点击一个菜单，就加载这个菜单对应的功能模块，放在一个新的选项卡或者别的什么地方展示出来。

在早期做这种系统的时候，一般都会用iframe来集成菜单，这种方式很方便，但是每个菜单页都要载入共同的框架文件，初始化一个环境，数据之间也不能精确共用。

所以现在我们做企业信息系统，不再适合用iframe来集成菜单，所有菜单的业务代码，会在同一个页面的作用域中共存。

这在某些方面是便利，比如数据的共享，一个选择全国城市的下拉框，在多个功能中都存在，意味着这些城市的数据我们可以只加载一次。

但从另外一个角度来说，也是一种挑战，因为数据之间产生干扰的可能性大大增加了。

我们回顾一下在传统的客户端开发中是怎么做的，早在经典的《设计模式》一书中，就提到了MVC模式，这是一种典型的分层模式。

长期以来，在Web开发人员心中的MVC，指的都是Struts框架的那张图，但我们单页应用中的MVC，其实更接近最原始的《设计模式》书中概念。

所以我们要在前端分层，而不仅仅把整个前端都推到视图层。

做单页应用，前端不分层是很难办的，当规模扩大的时候，很难处理其中一些隐患。

分层更重要的好处是能够从全盘考虑一些东西，比如说数据的共享。

跨模块的数据共享是一个比较复杂的话题，搞得不好就会导致不一致的情况，如果考虑到在分层的情况下，把各种数据来源都统一维护，就好办多了。

所以，以AngularJS为代表的前端MV*框架最重要的工作就是做了这些对于分层的指导和约束性工作，在此基础上，我们可以进一步优化单页应用这类产品。

前端的自定义标签体系

构建一个大型企业应用，最重要的是建立整套组件体系。

一般针对某行业的软件，长期下来都会有很多固定的模式，可以提炼成组件和规则，从前端来看，体现为控件库和前端逻辑。

控件库这个是老生常谈，在很多框架里都有这个概念，但各自对应的机制是不同的。

从写一个界面的角度来讲，最为便利的方式是基于标签的声明式代码，比如我们常见的HTML，还有微软的XAML，Flex中的MXML等，都很直接，设想一下在没有可视化IDE的情况用类似JavaSwing和微软WinForm这样的方式编写界面，毫无疑问写XML的方式更易被接受。

所以，我们可以得出初步的结论，界面的部分应该写标签。

很遗憾，HTML自带的标签是不足的，它有基本表单输入控件，但是缺乏DataGrid，Tree之类更富有表现性的控件。

所以绝大多数界面库，都采用某种使用JavaScript的方式来编写这类控件，比如：

• Nunctincidunt
• Proindolor
• Aeneanlacinia