以下純屬個人意淫：

隨著各種小程序的出現,前端開發面臨一個問題,就是同一個項目需要在不同的小程序展示,甚至還有h5版 pc web版,如果真對不同的端編寫同樣一套代碼,顯然是多余的，這有點像app的發展過程,自從ios和安卓出現之后,人們就從來沒有放棄過使用一種語言同時開發ios端和安卓端的嘗試,從phonegap到hybird再到rn,最終來到如今的flutter,

而真對小程序的多端開發思路也是一樣的，希望用一套代碼來生成對應平臺的代碼,最終完成生產率的轉化，這應該也是最終的方案,然而本文所討論的并不是這種方案,本文所討論的是關于在不知道有多少端的情況下 如何最大化的復用代碼,這本質上和flutter的愿景有點類似,flutter希望真正的統一客戶端界面開發,他希望無論什么樣的終端，都可以使用flutter來開發,并可以達到媲美原聲的效果。而我的方案則是將業務代碼與視圖代碼分開,然后視圖代碼使用不同終端的語言去編寫,同時調用業務代碼來完成具體業務。

我無法否認flutter代表未來,但就目前而言,flutter不會給出跨任何小程序的解決方案。

以下是跨小程序的解決方案：

?

1：代碼分離，最重要的是將業務代碼與應用邏輯代碼分離,分離的原則是最大程度將可以復用的地方抽離出來,

　　1：我們通常會把業務邏輯寫在model層,所以首先肯定要把model層抽離出來

　　2：所有有關于數據的處理全部抽離出來,這是對第一步的補充,理論上我們的程序應該是所有的數據都走model來取,同時model層會從不同的地方來獲取數據(api 本地緩存 內存緩存)

　　3：數據驗證最好放在Model層,這樣做的目的在于讓view層真正做到只關心展示和監聽用戶操作,同時Model層會定義具體的格式來告訴view層 哪一個字段驗證失敗

2：model層構建方案

　　一旦將model層抽離出來,就需要確定model層的技術實現,是自己定義一套通信機制 還是采用現成 方案,既然是跨多端 最好自己實現一套,而目前通用的有mobx

3：model層管理

　　既然將model層抽離出來,必然設計到model層的引入 更新等,可以采用npm私有庫的方式(雖然npm的建立初衷并不是此),因為使用npm可以很靈活的讓項目集成進model,同時更新model層也很靈活

4：model層設計

　　一旦model層獨立出來,model不在與具體的view交互，他所關心的只有業務邏輯,所以model必須提供一個配套的具體文檔以供view開發者使用

?

如何開發你的view層:

view單獨抽離出來之后,view層并不是不關心業務邏輯了,很顯然你需要關心你的業務邏輯 并在合適地方調用model的代碼,那如何提高view層的開發效率呢,我們這里可以參考有贊的業務型組件思想,view層的開發需要兩個人,一個人不需要關心業務邏輯,他只關心頁面的開發,（這有點類似于很久以前.net開發的時候前端人員把開發好的頁面直接丟給后端,）而另外一個人只關心項目架構和銜接model層,這樣每一個都有自己的角色。另外后期專門開發業務型組件的人可以將組件放到私有庫,(后期肯定會可以復用)

利用業務型組件來開發view,我們其實僅僅需要針對不同的終端開發不同的界面而已

?

這樣做的目的是什么呢？看起來只是定義了一堆規則,將原本可以很簡單完成的事情繞了一大圈才完成。

　　model層的抽離在于多端代碼最大程度復用

　　view層的劃分在于業務型組件的后期復用,這也符合關注點分離原則,不同的人關注不同的事情,有的人只需要關心界面實現和兼容性以及動畫處理,而另外一個人只需要負責關心項目架構和model層對接

這樣的劃分是否利于項目后期的可維護性？

　　我們想想如果不去這樣做的話,會是什么情況,我們可以使用taro實現一套代碼多端運行,然而從phonegap到RN,這種方式真的很好的解決了我們的問題了嗎,phonegap面臨的是體驗性不如原聲,而RN一直沒有解決關鍵組件性能問題，如果涉及到比較精細化 要求比較高的場景RN的性能問題就會暴露無疑,這也是為什么會出現flutter的原因,如果我們分別對每一個小程序單獨寫一套代碼,(我承認這是可行的),然而當涉及到比較大的新需求和邏輯改動,你需要陷入到多個小程序的汪洋大海中,

　　而是代碼復用方案,當遇到新需求和改動的時候,負責model層的人會專注于業務邏輯的改動,他不需要改動別的,而負責業務型組件的人 則只需要關注頁面中修改的部分 他也不需要關注業務邏輯改動的部分,而負責銜接model的那個人因為省去了修改視圖和業務代碼的工作,所以他只需要關心銜接部分就可以了,這種方案只適合于大型項目,如果用在小型項目絕對會得不償失,

?

最終的方案：

一個單獨維護的model層

針對不同終端設計到項目框架

業務型組件私有庫

?

1：然后將業務型組件從一個界面中剝離出來肯定是一個仁者見仁 智者見智的問題,不同的角度都會得到不一樣的結果,然后在這個問題上不應該交由技術人員去決定,而是交由產品人員去決定,既然是業務型組件,必然是業務的封裝,無疑 產品人員在這個地方比技術人員有更高的話語權

2：在封裝業務型組件的過程中,又會存在一個封裝度的問題,是盡量將配置外放 還是盡量將配置寫在組件內部,配置外放的好處是更加定制化,但是繁瑣的配置無意增加了使用人員的復雜度，將業務邏輯封裝在外部,只暴露出少許的必須可變的參數，所以應該盡量避免復雜的配置,畢竟業務型組件與通用型組件的使用場景不同。

?

最終的view界面編寫會有兩個形態：

? ? 1：只根據少許的配置文件即可快速得到一個定制化好的界面,字體 顏色 風格 行為 任何東西我們都不需要去關心

? ? ?2：一個類似.net webform的可拖拽的快速界面生成工具

?

轉載于:https://www.cnblogs.com/mrzhu/p/11298367.html

創作挑戰賽新人創作獎勵來咯，堅持創作打卡瓜分現金大獎

總結

以上是生活随笔為你收集整理的大型项目之一云多端的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。