相信前端开发框架中，很多都是用的vue-admin-element，或者是ruoyi-ui（这个其实也是vue-admin-element），不过就是已经对好了接口的，可以直接用的
代码如何组织？
代码的组织无非就是下面提到的这些，然后部分取舍
- 可维护性
- 冗余
- 复用
- 可读性
- 可扩展性
这就是框架要做的其中一件事情，框架要去做解耦和分层，这时候就会MVC，MVVM等概念的出现，都是为了更好的组织代码去实现一个功能，但同样的，这也给框架带来了入侵性，你无法平替到其它的框架平台
回归正题
我相信很多同行的项目里面都会有这个
这是ruoyi-ui的api和views代码，他这里的写法是ui对应api请求
因为官方是这样写的，所以后续二开的项目中基本也都是这样写，新建一个views的子文件夹，然后再新建一个api的子文件夹，这两个文件夹名字一样，在文件里面再建vue和请求js
首先第一个问题就是冗余
- 无法避免后端的api接口只在这一个页面上用
- 按照之前的做法就是再建立一个api文件，去对应ui，这就带来了很大的冗余
- 因为这个冗余就会带来第二个问题
第二个问题就是乱
- 项目开发中但凡有一位同事复用了api，可维护性立马下降到冰点
- 也就是views子文件夹复制一份然后api的迁移，也就是模块迁移
- 这就带来了第三个问题
第三个问题文件夹复制
叫文件夹，其实更应该叫模块，相信开发的时候都是把基本差不多的功能页面放在一个views下面，也就是一个模块的功能全部放在一起，所以感觉叫模块比较好
比如有这样一个场景：
- 来了一个新的项目，新项目里面有一个模块和这个项目里面的一个模块很像，所以项目经理就说复制一个这个模块出来，然后进行改
在代码组织中：
- 后端：基本上是一个模块就是jar，所以请求也是统一的，全部放在这个jar中，所以后端在迁移的时候就是直接复制这个模块生成一个新的jar，然后统一修改请求，再改改数据库就ok了
- 前端：如果严格遵循ruoyi-ui的方法其实复制也是很简单的，但是无法避免有同事给你复用其他的api，然后复制出来的模块这个api你就凉了，你需要各个页面去找，去做迁移，然后改api前缀，这个工作量无法预估，且无法保证是否完全迁移完成
方案
针对上面的问题以及在不修改工程基本结构的情况下，api的组织最好的方案就是跟着后端走，相信springboot的api组织应该是最好的，不然这个框架也不会活这么久，生态还越来越好
所以api组织中个人认为这样分是最好的
比如有url：
- /base/name/url1
- /base/name/url2
- /base/name/url2/urlchildren1
- /base/name/url2/urlchildren2
- /base/name --- get
- /base/name --- post
- /base2/name/url1
- /base2/name/url2
- /base2/name --- get
- /base2/name --- post
那么文件结构就是这样的
- api
- base
- name.js
- baseNameUrl1()
- baseNameUrl2()
- baseNameUrl2Urlchildren1()
- baseNameUrl2Urlchildren2()
- baseNameGet()
- baseNamePost()
- name.js
- base2
- name.js
- base2NameUrl1()
- base2NameUrl2()
- base2NameGet()
- base2NamePost()
- name.js
- base
也就是方法的名称就是完整url的驼峰，这样个人认为有几个好处：
- 因为是完整url，所以方法的名字是唯一的，不需要担心重复，这个springboot启动的时候会检测url唯一，不唯一就会报错
- 方便定位，很多时候我们都是看url去找方法，这样写url的定位一目了然
- 没有冗余
- 项目迁移，后端复制一个模块，你就复制对应的api和views，然后全局替换路径即可，不用担心缺胳膊少腿
最后 个人意见，不许勿喷
欢迎关注公众号致心空间：O(∩_∩)O😁
