有 网友 提到 :
“复杂的页面,一个页面加载的模块多,各种异步请求,页面渲染,jquery链式编程操作dom数过于频繁。现在的前台越来越复杂,逻辑臃肿。”
哎, 所以 我说, 要改成用 同步调用 。
什么是 同步调用, 就是 后端代码 里 调用 数据库 那样 。
如若不然, 还沉浸 在 “回调” 带来的 光辉的技术感 里的 话, 回调地狱 无法解决 。
现在 大家 都 以 “回调” 为荣, 以 “异步” 为荣, 以此 为 潮流, 以此 为 高效, 以此 为 进步, 以此 为 先进 。
这是 错误 的 。
前端 Js 里采用 AJAX 异步回调 的 方式 是 * 的, 事实上 当年 前端 Js 开发人员 很羡慕 其它语言 比如 Java C# 这样 可以 同步调用数据库 。
而 Js 没有这个能力 。
这大概是因为 Javascript 是 单线程 模型 吧 ! 不能 Sleep() , 也不能 Wait() 。
我强调一点, 程序员 要对 程序 有 控制感 。
太多的 回调 把 程序 切割 的 支离破碎, 这样的 代码 是 病态 的 代码 。
当然大家可能会说 “异步回调 提升了效率 …… 某某框架 是 回调 的 架构, 所以 速度 如何如何 的快, 可以支持 多大多大 的 并发量 ……”,
对此 我不想多说, 我今天在 QQ 群 里说了很多 。
总之, 且 不论 “异步回调” 是否 真的 提升了 效率, 我想引用 大家经常 引用的 一句话 “代码是写给人看的”,
还有 一句话 是 “能用硬件解决的事不要让软件来解决”,
还有一句话 是 “硬件是最廉价的”,
说了 那么多效率, 有没考虑一下 “代码是写给人看的” 好伐 ?!
而且 异步回调 是否真的能带来 效率 提升 这个 还 值得怀疑, 我只是觉得, 把 架构 搞得 很复杂, 效率 肯定 好不到哪去 。
关于 异步回调 是否能 提升性能, 可以参考 《后线程时代 的 应用程序 架构》 https://www.cnblogs.com/KSongKing/p/10228842.html
不过 Js 现在 学 C# , 搞了个 await 关键字, 看起来能实现一个 “伪同步”, 至少 代码 不再是 异步回调, 是 顺序 的 。
还行, 这问题就先过了吧 。
接下来要说 第二个问题, 就是 页面 模型, 或者说 页面开发架构, 或者说 页面控件模型, 或者说 页面控件架构 。
业界 已经被 各种 “前端框架” 荼毒多年 。
前端界 已经被 各种 “前端框架” 荼毒多年 。
这是 现实, 也是 事实 。
可以看看我写的 jlet https://www.cnblogs.com/KSongKing/p/9455238.html,
jlet 是一个 简单 的 前端 Js 库, 重要的是 提出了 “库” 的 思想, 为 前端架构 指出了一个 方向 。
我不赞同 MVVM , MVVM 同样是一种 过度封装 的 思想,
我认为 好的做法是, 提供 一个一个 封装 好的 控件, 用 代码 调用 控件 的 属性 和 方法 。
不要 用 各种 “UI 框架” 来 绑架 开发方式,
也 不要 用 MVVM 等方式 把 控制逻辑 绑架 到 控件 里,
程序 就是 程序,
程序员 应该 对 程序 有 控制感,
过度 的 控制反转 会 使 程序员 极大 的 丧失 对 程序 的 控制感 。
少搞框架, 少搞声明式 。
jQuery 和 一些 前端框架 会用 “声明式” 的 方式 来 做 用户输入校验, 比如 通过 Html 标签 或者 控件 的 属性 来 声明 这个 控件(如文本框) 要 作 什么样的 输入校验(如 数字格式、日期格式) , 然后 在 点击按钮 或者 Form 提交 的 时候, 由 框架 统一校验 。
这种方式, 看起来 高端, 维护的时候 蛋疼 。
好的方式 应该是, 提供一些 Util 方法, 如 Util.CheckNumber(), Util.CheckDate() ,
然后 在 按钮点击 事件函数 里 直接写 if 代码判断, 如:
if ( ! Util.CheckNumber( …… ))
{
Util.Alert("xx 应 输入 数字 。");
return;
}
这种做法, 看起来代码多了, 但 简单直接, 清楚明了, 尤其 有利于 维护 。
我在 《Web-Business-Application-Solution》 https://www.cnblogs.com/KSongKing/p/9455047.html 中 提出过:
“
少搞一点 封装, 少搞一点 控制反转(Ioc), 少搞一点 AOP, 少搞一些 “声明式”。
不要隐藏太多代码,让 代码 回归 代码。
是 找回 80 年代 写 Basic 的 那种感觉 的 时候了。 ^ ^
”