Web 技术研究所

我一直坚信着,Web 将会成为未来应用程序的主流

逻辑前移

  我一直都倾向于把繁重的逻辑丢到前端,后端只做安全校验之类的事情。比如一个列表的数据量如果很有限,可以一次把全部加载下来的话我就希望前端自己做排序和筛选。这么做不仅可以减轻对后端的压力,还可以避免发起多余的请求,让用户的操作变得更流畅。
  对于前端展示的各种复杂筛选器,后端要实现其实也很不容易。以前做小项目的时候对这种事情的处理我总是直接拿前端传过来的参数拼成 SQL 语句去查询,只要给 WHERE 后面加一堆条件,实在不行就 join 几个表进去。然而这种做法只能用来玩。对于重量级的表而言,复杂的查询条件就是致命的,更何况联表的条件查询呢?于是在大型项目中一些边缘的筛选查询都不是直接交给数据库,而是被放到业务代码中来做的。说白了就是后端开发者在为前端的展示的逻辑写代码。
  这种程序级别的筛选完全可以通过框架封装掉。比如后端的 API 框架中解析前端请求 URL 中一个名为 WHERE 的参数,然后在框架内对结果做进一步过滤。这里只是一个例子而已,字段叫什么都好,只是这么一套东西确实可以降低后端业务上的开发成本。但我依然希望由前端来处理这些与展示交互密切相关的逻辑。顺便提一下。筛选逻辑前移后,开发者可能完全通过变量来保存筛选器的状态,不会再像从前那样让数据从 URL 开始流下来。于是就出现了之前喷过的问题 。不过这只是交互上的细节问题,无论如何我还是希望将筛选类的逻辑尽可能地前移。
  除了筛选类逻辑外,还有一些即使前移也不会给后端带来任何好处的东西。比如购物车的价格展示之类的,这种将来会涉及写操作的展示。由于后端总是需要做安全验证,所以它总是需要做一次这复杂的逻辑。这类逻辑搬到前端的唯一优势就是减少网络请求,让用户操作更流畅。最典型的就是各种表单验证。实际上所有表单验证后端都必须做一次,然而很多项目中的表单验证不仅后端做,前端也做。这样增加工作量、增加维护成本,换来的就是用户体验(我的想法是连表单验证都这么做了,筛选器有什么理由不这么做呢?)。
  前面说的购物车是个比较典型的例子,它比一般表单验证的逻辑复杂地多。这类前移对后端没有任何帮助并且逻辑复杂到需要几十上百行代码才能搞定的逻辑可能就不应该前移了。如果购物车的展示逻辑只是做简单的加法乘法运算,也许我会考虑前移。但如果考虑上各种折扣、优惠活动等等一些列产品经理挖出来的坑,那还是让它继续安静地呆在后端吧。
  剩下的就是权衡用户体验与程序的开发和维护成本的问题了。一旦问题提升到哲学的层面上,我觉得我再瞎哔哔便毫无意义。
网名:
34.203.245.*
电子邮箱:
仅用于接收通知
提交 悄悄的告诉你,Ctrl+Enter 可以提交哦
神奇海螺
[查看全部主题]
各类Web技术问题讨论区
发起新主题
本模块采用即时聊天邮件通知的模式
让钛合金F5成为历史吧!
次碳酸钴的技术博客,文章原创,转载请保留原文链接 ^_^