背景

由于之前的數據庫防火墻產品與數據庫審計產品使用的是同一套代碼，隨著兩個產品功能的差異越來越大，代碼的冗余度和偶合度越來越高，為了便于后期維護以及添加新功能，所以基于原來的項目代碼，進行了代碼結構拆分。

注意：本次拆分只拆分了可以拆分的部分，有的模塊例如：規則、關于我們，是沒有進行拆分的，一是有的模塊很簡單，沒必要拆分；二是有的模塊原先寫得代碼偶合太嚴重，無法拆分，如果要拆分，需要花費大量精力去梳理代碼，同時還要后端配合拆分。

目的

將此次代碼拆分方案記錄下來，便于后來的開發人員快速熟悉項目結構。

拆分前流程設計

項目拆分前，區分數審和防火墻功能的流程如上圖所示。

訪問系統時，先加載入口文件 main.js，然后加載登錄頁 login.vue，加載登錄頁的同時獲取產品模式并保存到 session.storage.platformType 中，接著用戶登錄系統進入具體頁面，該頁面同時包含了數審和防火墻的功能，根據 session.storage.platformType 保存的值來判斷，具體顯示哪個功能。

目錄結構設計

項目拆分前的目錄結構如上圖所示。

該目錄結構是初始化一個 Vue 項目時的基本目錄，根據目錄結構，基本上看不出該項目包含了兩個不同的產品，也不知道不同產品模式下會加載哪一部分文件，結構不清晰。

存在的問題

通過分析，可以發現當前的系統流程和目錄結構是存在很多問題的，大概總結下：

加載登錄頁的時候才獲取產品模式，如果登錄頁加載完成，而產品模式還未獲取或者獲取不到，那么登錄頁顯示的產品信息有可能是錯誤的； 每次進入一個具體頁面，如果同時包含了數審和防火墻的功能，都要重新判斷一次，當前的功能是數審的還是防火墻的； 目錄結構不清晰，不清楚哪些模塊是公共模塊，哪些是數審獨有的模塊，哪些是防火墻獨有的模塊； 可維護性和可擴展性差。數審的代碼和防火墻的代碼混在一個文件內，改代碼的時候需要重頭看一遍才知道哪塊代碼屬于數審，哪塊代碼屬于防火墻。如果想要添加一個功能，還得繼續加邏輯判斷，代碼越來越臃腫； 業務邏輯混亂，與后端通信使用了同一個接口。 拆分后流程設計

項目拆分后，區分數審和防火墻功能的流程如上圖所示。

訪問系統時，先加載入口文件 main.js，該文件中寫了路由攔截相關的邏輯，在路由攔截時，如果沒有產品模式，則要先獲取產品模式，否則會被攔截，進不去系統。獲取產品模式后，根據當前產品模式，會注冊對應的登錄頁、路由配置、接口請求等。當注冊完畢后，每次訪問具體的頁面，都應該是獨立的模塊了。

目錄結構設計

項目拆分后的目錄結構如上兩個圖所示。

該目錄結構經過拆分，已經可以清晰地看到不同產品之間分離出來的文件了，從入口文件開始，經過路由攔截后，會加載指定的登錄頁，然后把對應產品需要的文件合并到公共文件中。比如：http 請求、路由配置等。最終結果，程序只會把需要的文件加載進去。

解決的問題

經過重新設計，解決了當前項目存在的一些問題：

在加載登錄頁之前，通過路由攔截，必須先獲取產品模式，才能進入系統，登錄頁是在獲取到產品模式之后才加載的，不會出現產品信息顯示錯誤的問題； 只有在第一次進入系統或刷新頁面的時候，才會重新獲取產品模式，合并產品模式對應的文件，合并的文件是拆分后的文件，不需要在文件內再次判斷該有數審的功能還是防火墻的功能。 目錄結構清晰，防火墻相關的功能模塊文件都放在 views-fw 文件夾內。 提高了項目的可維護性和可擴展性，降低了代碼的偶合度。數審的代碼和防火墻的代碼基本已經拆分開，如果想要添加一個防火墻的功能，只需要在防火墻相關的文件夾內新增對應功能模塊的文件即可。 業務邏輯清晰，與后端通信使用的是不同的接口，公共模塊使用的接口按原來的不變，數審獨有的接口在 url 前面增加了 audit 前綴，防火墻獨有的接口在 url 前面增加了 firewall 前綴。 關鍵代碼

/** * @Name: main.js * @Author: cqfeng * @Description: 項目入口 js 文件 * @MainFunction: 引入和注冊一些全局資源 **///...省略的代碼...// 路由攔截，使用全局導航守衛beforeEachrouter.beforeEach(async (to, from, next) => { // 如果沒有產品模式，先獲取產品模式 if (!store.state.productMode.productMode) { await store.dispatch(’productMode/SET_PRODUCT_MODE’); }//...省略的代碼...

/** * @Name: product-mode.js * @Author: cqfeng * @Description: 產品模式相關邏輯處理文件 * @MainFunction: 保存當前產品模式，根據不同產品模式配置 產品登錄頁、http 請求 等資源 **/import Vue from ’vue’;import portService from ’@/assets/js/service/http/http’; // axios請求import router from ’@/router/index’; // 默認路由配置，動態路由配置import httpAAS from ’@/assets/js/service/http/http-aas’; // 數審獨有的 http 請求import httpFW from ’@/assets/js/service/http/http-fw’; // 防火墻獨有的 http 請求import globalConstant from ’@/assets/js/const/global-constant’; // 項目全局常量export default { namespaced: true, state: { productMode: ’’, // 產品模式，進入系統或刷新頁面時獲取 }, mutations: { // 修改產品模式 changeProductMode: function (state, value) { state.productMode = value; }, }, actions: { async SET_PRODUCT_MODE({ commit, state }) { let res = await portService.getProductMode(); if (res.data.code === 0) { commit(’changeProductMode’, res.data.data.productMode); } // 如果是數審產品 if (state.productMode === globalConstant.COMMON.AAS) { // 設置產品登錄頁 router.addRoutes([ { path: ’/login’, name: ’login’, component: resolve => { require([’@/views/login.vue’], resolve); }, } ]); // 合并 http 請求，掛載到 Vue 原型上 Vue.prototype.portService = Object.assign(portService, httpAAS); } // 如果是防火墻產品 else if (state.productMode === globalConstant.COMMON.DBSG) { // 設置產品登錄頁 router.addRoutes([ { path: ’/login’, name: ’login’, component: resolve => { require([’@/views/views-fw/login.vue’], resolve); }, } ]); // 合并 http 請求，掛載到 Vue 原型上 Vue.prototype.portService = Object.assign(portService, httpFW); } } }};總結

經過拆分，數審和防火墻的代碼目錄已經算是基本分開了，這個過程花費的力氣也很大，也引發了我的一些思考，一套代碼多個項目的這種方案是否算好的方案，還有沒有其他更好的方案。如果項目一開始，就按照一套代碼多個項目的設計來開發，會不會后期的維護成本會低一些？這些問題我也沒有答案，希望后來者能夠繼承歷史經驗，更好地開發出優秀的項目。

其他實現方式

起初設計拆分方案的時候，有兩種方案，一種是通過獲取產品模式動態改變當前產品功能，一種是在打包時通過打包參數打包指定產品包。最終的方案是選擇第一種。但是，在這個過程中也參考了一些網上的實現方案，這里列出來方便以后需要用到進行參考。

//www.jb51.net/article/188869.htm

//www.jb51.net/article/207835.htm

以上就是vue 項目代碼拆分的方案的詳細內容，更多關于vue 項目代碼拆分的資料請關注好吧啦網其它相關文章！