JavaScript 是一种优秀的脚本语言。
在 JavaScript 的诞生之初，便于 浏览器 密不可分，如今它更是到了服务器中大展身手。
但是这里不叙述服务端的开发建议。
Script 翻译过来就是 脚本，而前面所加入 Java 则是指现如今仍然流行的开发语言：Java。
在 Java 日常开发中，常使用 MVC 的模式进行开发，那么使用 JavaScript，不借助任何前端框架，我们可以使用这个模式编写出执行高效的前端页面脚本代码吗？
答案是 OK 的，如何做到？
了解 MVC 的一些常识：
MVC的全称是： Model（模型）、View（视图）、Controller（控制器）
它们各司其职，也为协同办公提供了底层上的支持：比如有的开发者负责模型搭建，有的则是开发视图（也就是我们所说的前端）、以及后台业务处理的控制层。
这是最基础的分工模式，还延伸了 Dao 层，也就是单纯与数据库打交道的。
各类原理图片网上亦有很多，这里不再叙述。
延伸：如何 JavaScipt 可以像 Java 开发后台那样游刃有余的开发前端？
前端脚本所需要实现的主要功能大致如下：
- 处理与服务器交互的数据的
- 处理与用户交互的数据的
- 处理界面点击响应的
- 处理缓存的
- 处理页面效果的
它们之间的依赖我大致整理了一下：
界面点击响应 -> 页面效果 -> 用户交互 -> 服务器交互
页面效果 -> 缓存 -> 服务器交互
简单梳理之后就可以发觉原来前端也可以高效开发！比方说，页面效果指的是用户所看到的，属于视觉层
而有些内容则是动态生成的，这就意味着需要与服务器进行交互拿到数据。
但是服务器如果同时在线的人数过多，那么每初始化一次就需要拿取数据，显然可能会不堪重负，所以加入了缓存
界面初始化后，用户会进行操作（界面点击响应），点击后的视觉会发生变化（页面效果）以让用户知道他以及成功操作，需要等待。
之后将用户交互产生的数据进入服务器交互区，上传给服务器处理。
就这样，一个前端的基本功能互相依赖，就变成了我们日常所看到的网站。
如何细分为脚本区域？让分段开发更有效？
我所建议的是，前期先分为多个文件进行开发，注意文件之间的顺序引入：因为HTML的解析是由上而下，上方的脚本是无法访问下方脚本的API的，除非有全局变量
<script type="text/javascript" src="/xx.js"></script> <script type="text/javascript" src="./xxx.js"></script>
若果是按上述代码所写，基本上 xx.js 的代码初始化中带有 xxx.js 的API，则会报 define 错误。
谁让 xxx.js 还没加载呢，所以起初分为多个文件开发，一定要注意顺序问题，或者都不进行初始化，等到最后一个文件加载时才进行初始化便不会报错。
好了，问题稍微注意下就好，这是针对刚进行开发的开发者提供的注意事项。
分为多个文件：
- 异常处理.js
- 缓存读写.js
- 数据库交互.js
- 数据服务.js
- 实体类.js（参考Java的编程模式）
- 界面效果.js
- 界面事件处理.js
大致分为七个文件，顺序亦按照上述所布置。
异常处理是处理如同断网、或者被某个扩展脚本阻拦产生的错误等处理，以便让用户明确地知道当前操作失败。通常有效的方式是发出一个弹窗（视情况发出不同类型的模态窗体）。
其它不再叙述。
数据库交互文件无非是使用 Ajax 的方式进行提交，收取数据，关于 Ajax 的资料网络上非常多，JQuery 框架也集成了功能。
这里指的注意的是，要划分好后台提供的API，比方说：
后台提供了初始化页面的 JSON 数据，并且是一天才更新一次，而且参数是根据登录 Cookie 决定的，那么可以根据这样进行开发：
class Database extends Cache{ constructor() { // 只初始化一次，且当天数据保持不变 this.INIT_PAGE_DATA = null;
} initPage( cookie ){ // 查询是否有缓存的 Cookie 当前页面数据 -> 继承了缓存 API，可直接使用 this 关键字 this.queryCookie(); // 没有缓存 -> 进行 Ajax 操作拿到 数据：data this.INIT_PAGE_DATA = data; // 进行缓存到 Cookie 的操作 this.cacheCookie(); } }
如此一来，就算是后台开发人员，只需要稍微了解 JavaScript 的常识，就可以开发自己擅长领域的脚本！
数据库编写者可以根据字段，写出严谨的前端实体类（好吧其实Java后台的实体类通常也是根据数据库字段而开发编写的）
在担心 class 关键字没有太多浏览器支持吗？其实那已经成为过去式了。
使用 function 关键字虽好，但是 class 操作价更高呀
至于原型链等深层的原理，这里不再概述，以后有时间再出相关的随笔吧。
那么实体类该怎样写才能做更多的事情，不至于产生贫血模型呢？
答案是让它们各司其职，数据写入前进行检查，顺道操作一下相关的API，这样界面事件处理的开发人员就不用写太多行来实现某个业务了。
比方我只需要一个实体类，载入所有数据后，将其提交给后台，保存在数据库里：
class entity_user{ constructor() { // 用户的名称 this.name = null; // 用户的年龄 this.age = null; // 不写太多了 } getName(){ return this.name; } setName( name ){
// 如果传入产生为空，那么其实是真的想设置为空 if (null == name ) { this.name = null; return; }
// 查查类型是不是 String，不是便抛出异常 if (typeof name !== "string") {
// 长度是否大于 1，也就是传入的是不是空字符串，是的话再抛出异常 if (name.length >= 1) { this.name = name ; return; } throw new Error("the parameter is incorrect"); } throw new Error("parameter not a string"); } }
这样一来，我们仅需要实例化这个实体类，插入用户交互产生的数据，然后将数据直接导入：
// 某业务方法内 Start try{ let user = new entity_user(); // 假设用户借助了某种工具就是要给你空字符串 user.setName(""); // 使用数据服务API将其提交给数据库交互处理 } catch(e){ // 其实可以自定义异常 } // 某业务方法内 End
不必担心会将空字符串传给服务器，因为在这里我们已经拦截了。
而自定义异常可以使我们像 Java 那样一层层的进行捕获，意味着可以更精准的处理某个异常。
异常处理中，则可以调用最顶层的 异常处理API ，根据不同级别，给用户传达不同级别的错误信息。
哦，对了，数据服务API 是区别于 数据库交互 的，它们的关系为：
数据服务 继承 数据交互 继承 缓存 继承 异常处理
也就是说，其实业务层（界面事件处理）根本不去想数据要经过怎样的流程，要怎样进行 Ajax 交互。
只需要简单的一行代码，塞入对应的实体类，就可以将实体类的数据提交给后台服务器。
这样一来，不觉得开发效率提高了很多很多吗？重要的是，它可以多人协作，各自编写各自的代码。
我总是说各司其职，也只有这样，才能让人更专注于某一件事。
其实这样分段编写，也便于扩展程序的新功能，而不是说：我们需要新增某个页面上的功能。就大费周章的重构原先的代码。。
大概就写到这里了。
PS：原先标题是想写 实体化开发 的，但是想了想发明新词可能不大好，所以现在就是你们看到的模块化开发啦。
2020/2/6 下午 写于揭阳
转载请附上本文博客地址！