企业应用

2014-10-11 • warmhug Tags: js

• 前后端协作
• 组件及代码

这半年多一直都在做企业应用类型业务相关的开发，多少有些心得与体会。这里聊下企业应用开发，从“前后端协作”及“组件和代码”两方面说起。

前后端协作

企业应用大多是「重数据」、「重业务逻辑」、「给少数专业人员使用」、「视觉设计要求低」、「交互不必太创新」的类型，这就意味着前端开发「不必兼容所有浏览器」、「不必太在意页面性能」，一般是扮演支持角色；后端开发就要包揽绝大部分工作量、当然也包含html/js/css等原本属于前端开发的工作。

所以、前后端常见的工作协作模式是：前端提供各种做好的业务组件、使用demo；后端直接拿这些组件demo套用到业务中、并写上业务相关的代码。当后端同学碰到问题：如组件用不起来了、一些组件没提供的css样式不会写了、较复杂的交互效果搞不定了，就让前端同学来支持下。

随着mvvm开发模式及AngularJs的流行，很多企业应用开发也使用了它。也带来了新应用的两种模式：

• 完全的SPA（单页）、前端来渲染。
  • 这种是典型的使用方式、也是很彻底的前后端分离，后端只提供封装好的数据接口，其他工作都交给前端来做。
  • 但这样前端会增加「管理页面路由」、「页面状态控制」、「页面权限控制」等不少额外的成本。
• 非SPA、前端来渲染。
  • 表现在「页面路由、跳转、权限控制、状态管理」大多还是后端来做。
  • 但后端velocity页面上的vm语句很少，可能只是在vm变量里放置页面需要的数据，但页面渲染工作都交给html/js。

这两种模式、都面临一些同样的前后端协作问题：

• 传统方式，前端提供组件和demo，后端拷贝修改并套用业务数据即可：

  • 后端不用拼装json，直接在vm页面上写数据变量。后端很容易独立写或修改vm。
    • 对于列表表格类型(map、枚举等)，用vm的for循环生成列表htm+data
    • 对于数据验证，用Ajax方式、返回true false的结果
    • 对于表单提交，用同步方式提交、刷新页面
  • 联调阶段：前后端耦合小、开发能直接把数据填到相应坑位查看数据及展示对错即可、而不必等待前端修改
  • 不好的地方：
    • 页面能被随意修改，velocity里可能掺杂不少业务逻辑，页面很可能会越来越难维护
• 现在，好的地方：
  • 前后端分离的更好，对于后期维护比较简单

• 现在，增加的一些成本：

  • 几乎所有类型的数据都需要转为json格式，对不同的后端数据类型都要做转换
    • 但如提供给页面展示用的：input、table等原本就不必为json类型
  • 由于数据格式易变（业务变动比较频繁），改变之后前后端都需要修改代码（原来vm方式也同样有此问题，但开发改vm会更熟悉点）
  • 数据坑位都用特殊的前端代码表示，如ng-model="data"、``、ng-repeat="key in list"等，另外这些数据一般还需要再经过二次加工转换。
    • 这会导致后端改页面更困难、对前端依赖更严重。
  • 开发同学大都对jQuery有了解，简单页面交互自己用jQuery一般能搞定；但现在可能会碰到jQuery与angular协作的冲突。
  • 项目如果是「有多个开发、只有一个前端」，因为前端工作量变大，到联调阶段、问题一多 前端就应付不过来。

• 现在，可能遇到的angular使用问题

  • 使用时入门成本较高，需要转变思路「从操作dom」转为「操作model」，初期转变成本高、表现为：
    • 删除列表list某一项时，仍然$('li').remove()，而不是删除相应条目的数据。
    • checkbox radio等设置时，仍然$('.xx').attr("checked", "checked")，而不是直接设置数据
    • 显示隐藏页面某一部分，仍然$('.xx').hide()，而不是使用ng-hide="data"设置data
  • angular的directive指令、只用在html上做标记和配置、就能自动运行，使原本的静态html标签产生神奇的动态效果。
    • 但这增加了遇到问题时的调试及修改代码的困难、有时候甚至让人找不到该修改哪里~ 解决办法：在设计directive指令时、所写的配置项更集中、更清晰易懂，减少使用困难。

组件及代码

代码组织上、代码文件组织上，都该以清晰、简易为主，这样遇到问题就能够马上定位到问题所在。如directive的书写和使用，做到什么程度才好呢？

• 让不太了解这些的人、也能很快一眼看懂
• 使用中碰到问题时快速找到可能出问题的源码位置

有个常见的问题：我们到底该使用「功能全面丰富的集成式」组件；还是「简单专一」多个组件搭配起来使用？前者可能大而重、多数功能不一定用得上但可供备用；后者小巧玲珑但搭配使用成本可能比较大。

另外更重要的是组件常见的「细节功能」是否贴心全面、是否能与其他组件或代码能很好的共存。以下举些实例：

• 项目有动态表格的需求，使用了angular的ng-grid组件，就发现了这个外表功能强大的组件细节上的一些不足：
  • 表格行列很多时、它在固定的容器宽高下、会出现内滚动条。但业务上有高度自适应需求、它没有提供良好解决办法。
  • 表格的「单元格高度」是固定的，不能随着内容多少改变，需要自适应高度时需要再另外设置。
  • 单元格内“只考虑了”文本类型的数据，像图片、按钮组等其他稍复杂类型的数据没考虑。
• 写输入框的「数据合法性校验」的代码(或组件)
  • 一般只考虑“输入框的数据变化时”去验证。
  • 但其实输入数据不变、其他条件变化时也很可能需要验证。（如验证url、其他配置项等变化）

• 不同代码协作问题：项目中使用了checklist-model组件，它主要使用checklist-model代替ng-model，能够简化单纯使用checkbox时多写的一些代码。但这个库的issue里提到一些问题How to validate等、反映了这个代码可能并不能与其他代码很好协调工作。

• 还有其他的如：angular-strap组件库中的select组件多选或单选选中的内容过长时，在一行显示不全的问题；下拉的数据条目过多需要有内滚动条、不然会超出页面高度数据被遮挡。datepicker组件没有内置默认的清空按钮。

以上说的都是出自业务中实际碰到的需求。所以、组件做的好必须要考虑许多实际细节需求。选择使用组件时也要考虑的充分、当某个组件不满足功能需求或细节点不完善时、就换个其他更完善的组件。