***************
更新：
1. mvvm 可以將網路層轉移到viewmodel 層中，這樣就不需要將網路層抽離了，因為本來就沒和 控制器耦合。
2. 每次使用蜂巢的時候 控制器一定要實現 服務的協議，不然蜂巢會崩，還很難找到原因
3. 蜂巢方案 雖然分離了控制器業務的耦合，但是引入了protocol 協議的耦合。同時需要維護 協議表 ，當跳轉的時候需要去協議表裡面找 對應的協議，然後再進行跳轉。對元件化的不好的地方就是引入了協議，當進行元件化的時候，如果不先引入protocol 那麼元件pod 的時候 就無法編譯通過，因此 要求在使用的時候 就已經把所有的模組都在core 核心類註冊了服務，寫好了protocol。這點缺點也很明顯。
按照以往的思路，所有的東西都封成view 層級，就可以給各個控制器使用了。抽離的時候只需要把view剝離出來，而不需要關心跳轉的邏輯業務。
於是 ，元件化的方案都提出了中間層的管理方案，通過中間層來找到模組、並**各個模組之間的訊息傳遞，所以元件化的核心思想就是提出中間層。在提出中間層的乙個很重要的選項就是盡可能的降低耦合度，oc語言中 能夠降低耦合度的 無非是runtime protrcol 和 category 這幾種，網上已經有很多種元件化的方案了，選擇適合公司的元件化方案即可，不再比較各個方案的優劣了。
團隊選用的是阿里的蜂巢方案，是用的協議的方式來提供元件間的通訊，每個業務對應乙個協議 ，只要建立乙個協議，然後將協議和業務（控制器）關聯在一起，就可以通過協議找到業務（控制器)。來進行跳轉了。還是拿a 跳轉到b業務來舉例， 現在給b註冊了乙個協議c ，當a 需要跳轉到b控制器的時候，不需要引用b的標頭檔案， 只需要 引用c 這個協議檔案 就好了 ，然後用蜂巢的管理類，就可以拿到c 對應的業務，再判斷c 是否為uiviewcontroller、 如果是uiviewcontroller 就可以跳轉了。這樣，當我把a模組抽離出來，就不會需要引用b相關的全部內容了。唯一需要的就是c這個協議， 這個協議 我們放在核心層的註冊服務模組裡，後面再講講這個核心層。除此之外，a 需要把引數傳遞給b 的時候，我們可以把方法和引數都寫在c的協議裡面，b 會實現協議的方法，就能夠實現引數的傳遞了。反過來說，b 讓a 做的事情，就可以註冊a的協議，把引數方法都傳遞給a的協議即可。
當然阿里的這套方案不能解決全部的問題，乙個很明顯的問題 ，就是引數傳遞都是正向的，當我們希望逆向傳遞數值的時候，蜂巢的方案並沒有提供解決思路，但逆向傳值又是業務中經常出現的部分，所以開始尋找相關的解決方案。最後用的是 使用routable後的思考 這篇來解決的。解決思路是給nsobeject 新增乙個分類，
給分類用runtime新增乙個delegate物件，delegate物件遵循某個協議，這個協議裡面寫具體的方法和內容，當b 想把訊息回傳給a的時候，只需要新增這個分類，就可以告訴通知**去處理了。a作為delegate物件，去實現**的方法，就實現了反向傳值。
業務層所需要考慮的基本就是這些，還需要考慮的就是基類層 和核心層，先說基類層，為什麼要存在基類層呢，拿控制器來舉例，最常見的操作就是導航欄跳轉後對導航條的設定，對分欄控制器的設定，是否要隱藏分欄控制器，導航條左右返回按鈕是否需要處理等等，如果不做統一的管理，就必須在每個控制器裡面寫上是否隱藏，是否修改等等，與其在所有的頁面裡面一遍一遍的寫，不如抽離乙個基礎類出來，減少業務類的**量，子類只需要設定顯示和隱藏的bool值，基類控制器就會在生命週期中管理了，也便於維護跳轉等等。至於和業務無關的東西，是否需要旋轉之類的，這些都寫分類實現，原因是基類不強求使用，如果基類要用的直接放在基類裡面就行了。其他的業務類根據需要新增分類就好了。我暫時是寫了導航欄的基類，控制器的基類，還有分欄控制器的基類。
然後是核心類， 核心類包含哪些東西呢，可以說每個業務模組可能用到的部分都屬於核心類，
拿網路層來說，頁面需要網路資料，網路資料都會分散在各個模組裡面，如果分散到業務層裡面
。可能a 和b 模組都要登入介面，那就麻煩了，到時候很難拆開 登入介面了，所以就放在核心層裡面，業務層需要繼承基類層，同時要引入核心層的部分，當然那些註冊的服務也是核心層的組成。
還是拿網路層來舉例，到底乙個怎樣的網路層架構 適合元件化的管理。我們知道兩點，一是網路層很難解耦合，而是網路請求資料到底給業務層怎樣的資料 合適，我認為是寫統一的請求介面，統一的引數介面，統一的請求成功，統一的請求失敗，然後讓成員自己去找這些方法來處理，但是每個介面又都不一樣，怎麼統一呢，那就只能繼承了。所有的方法回傳的數值都是介面模型本身，裡面儲存了你上傳的資料 和你返回的資料，父類只是乙個做這些事情的類，子類繼承父類後填寫上引數 和**什麼的，當控制器引用子類的屬性並且作為子類的**， 發起請求的時候，回應的訊息 會通過 **回傳給控制器，就會統一在**方法裡面進行處理了，這時候就可以判斷 這個返回的物件 是不是子類那個物件，如果是，代表找到 了對應的請求，就完成了網路層的處理，
在遷移的過程中，也變得更加容易，因為你呼叫了新的api 就是呼叫了新的子類而已，把舊的子類呼叫方法注釋了，在返回的結果裡面增加新的if型別就可以了。這裡當然還是用的ios應用架構談 網路層設計方案大神的方案，基本上他把每個方面都考慮全了，我們只是引用了這種請求返回的介面設計思路，把這一部分拆分出來而已
以上就是我們對元件化的框架完成的實踐，並作為新專案的框架思路。有個需要轉變思路的地點是pod化，元件化的方案最後都會把每個元件變成pod ，但我認為在專案初期最好不要太早做pod化。一方面這樣可以減少處理難度，當後期元件功能比較完善的並且元件比較成熟的情況下，再做pod 也不遲。
還有一點就是元件內部自己的訊息傳遞和跳轉 沒必要使用路由，原因是元件內部本來就是耦合在一起的，沒有必要增加額外的開支。
記一次頁面配置化的實踐
在日常專案開發中，我們可能會遇到一些專案，它們的文案可能會不定期改變，多個頁面有相似之處，但是相同中又有不同，比如有的直播活動，策略邏輯沒變，改了獎品 背景圖和banner，也可以叫做換膚 也比如一些產品的官網，會不斷加一些子頁面，但是風格都是統一的，但會改變布局和文案。這個時候，做為技術，我們會思...
巢狀事務的一次實踐
最近在乙個專案中，需要實現自動對賬功能，收銀機會定時對比本地和遠端的訂單，遠端發現缺少的，會自動補全。所謂補全，就是批量插入缺失的訂單。基於這個場景，就存在乙個細節的問題，因為插入訂單涉及兩個表，如果某些情況下，乙個表插入失敗，訂單插入事務需要回滾。但是不能回滾之前插入的訂單資料，顯然這裡就設計子事...
javascript元件化實踐
寫元件的能力是乙個前端工程師的基本能力。使用oo模式是逐步搭建複雜元件的最佳編寫方式。下面是使用es6的class方法編寫乙個監聽input輸入框，並展示輸入內容的基本元件。會持續更新，在基類中練習新增基礎功能。複製 使用es6語法，oo模式，使用事件訂閱 監聽基類 事件訂閱 監聽基類 class ...