用JavaScript编写业务逻辑？

Dear 丶 2022-07-21 02:43 303阅读 0赞

Web应用程序刚刚兴起并取代传统客户端应用程序时，技术热点在服务器端开发语言。从ASP、PHP到Java、ASP.NET，无论采用哪种技术，作为一个系统核心的业务逻辑都是用一种运行在服务器端的语言编写的。架构师习惯将一个应用系统分为多层，视图层、业务逻辑层和数据层等，而它们也都是以某种服务器端编程语言，结合html和sql等技术，在服务器上运行。JavaScript作为运行在浏览器中的语言，仅仅是用来完成校验、界面的零散修改等任务。那时候谁要是提出用这种辅助性的语言来编写业务逻辑，一定会被当成天方夜谭。然而时光流转，技术发展，Web系统越来越倚重JavaScript。JavaScript语言的能力和特性被彻底发掘，Ajax成为Web开发的常规，JavaScript框架层出不穷日新月异，昔日的天方夜谭越来越多变成现实。利用某个MVC模式的JavaScript框架，业务逻辑代码运行在浏览器中，通过RESTful服务和服务器交换数据，是越来越多功能丰富、外观华丽的Web应用的技术路径，推向极致便是所谓的单页面应用。  
在这种趋势下，一个必然会产生的问题就是业务逻辑真的应该全部从服务器端移到浏览器端吗？  
好处：  
1. 更快的响应。Web应用系统响应所费的时间一大部分是用在网络传输上。传统的Web应用每当要执行业务逻辑时，哪怕是很简单的计算，都要提交到服务器，再等待返回整个页面。等到后来采用Ajax技术，服务器端可以只返回执行业务逻辑后的数据结果，性能就大大提高。更进一步地，如果一开始就将应用的模型数据传输到浏览器，后续的计算都用JavaScript完成，只有当需要更新数据库时才返回到服务器，网络传输就更少，系统响应也就更快。而且，应用程序会用到一些无需持久化保存的临时数据，比如和界面显示相关的或者计算时用到的中间数据，对这些数据的运算也都无需在服务器端进行再传输到浏览器。这些因素的共同作用就使得Web应用在很多时候的响应速度可以达到本地应用的水平。  
2. 更简单的结构。一项功能通常既包括看不见的运算，也包括用户界面的变化。如果以传统的方式来实现，服务器端代码进行业务逻辑的计算，将结果传输到浏览器，JavaScript再修改html完成显示上的变化，分别用两种语言编写，服务器端发送数据前的编码和浏览器端接送数据后的解码也都需要专门的工作。将业务逻辑转移到浏览器端用JavaScript编写则会让代码变得更一致，结构更简单。  
3. 更好的伸缩性。代码分散到各个用户的电脑上执行，自然减少了服务器的负荷。

坏处：  
1. 用户环境的不确定性。不同用户的电脑配置、浏览器种类会给应用程序的表现带来不确定性。虽然说“万一用户禁止JavaScript运行怎么办？”这样的忧虑在如今显得有些杞人忧天，但JavaScript运行速度、浏览器对脚本的支持乃至缓存问题等用户环境上的差异导致的不确定性比起代码集中在可控的服务器端运行还是大得多。  
2. 代码的隐私性和安全性。用JavaScript编写业务逻辑代码意味着你的系统暴露在大庭广众之下。除却安全性上的顾虑，单单曝露于众这一点，就会让长期以来习惯于要保护代码知识产权、千方百计隐蔽、加密、混乱化代码的软件公司和程序员觉得彆扭，和失去隐私的感觉一样。不仅如此，服务器端的数据接口也变得外人可见，因而它们编写的安全性也需要提高。  
3. JavaScript。这一点实际上是见仁见智的。JavaScript与服务器端语言Java、C\#、Python、PHP比起来是不是适合用于编写业务逻辑的复杂代码，你是讨厌它的没有编译时检查、难于调试测试、语言设计上的缺陷还是喜欢它的简洁、灵活、函数式编程？这一点或许是对于一个程序员来说，采用新旧哪种开发模式的决定因素。

曾经的客户端应用程序，被称为胖客户端，以此对比Web系统所用的浏览器是瘦客户端。风水轮流转，如今随着一个系统中越来越多的代码用JavaScript编写，浏览器又逐步变成富客户端。然而背后的动因和逻辑都是一样的，那就是用户是上帝。前一次转换是为了省去用户安装和更新的时间，后一次转换是为了让用户享受到更快的速度和丰富的功能。在手机开发领域，模式干脆又回到了客户端——App，因为本地运行的App不仅速度更快、可以离线运行，还能调用摄像头、地理位置、话筒听筒等手机硬件功能，总之就是让用户有更好的体验，而这背后的程序员们则或者啃书本更新技能，或者长江后浪推前浪。