JavaScript的MVC模式嚮導

　　多年來，我總結出了一些MVC在Web應用中的規則。這些規則對我幫助很大，且避免了大型程式碼庫陷入混亂。可能術語上不同，但這些規則對於諸如Backbone和Ember的大多數客戶端MVC框架來說都是有用的。

　　一些框架在MVC的命名約定中有所不同，且在關注點的分離上也稍有不同。在這個文件中，controllers（控制層）是models（模型層）和views（檢視層）的粘合劑，views（檢視層）是HTML模板，models（模型層）僅單純處理資料儲存、檢索和裝飾。這與Backbone和Spine的術語基本相同。Ember有著類似的定義，不過在分離DOM訪問控制層邏輯上更深入了一步。

　　控制層

• 控制層是模型層和檢視層的粘合劑。處理大部分邏輯問題甚至管理問題。保持瘦控制器

• 任務父子控制器之間的通訊均應使用事件（不要通過父控制器的例項來傳遞）

• 應該只知道其子控制器

• 應該限制單個元素，不要訪問或修改DOM的其它部分

• 應該有唯一的類名且所有與控制器有關的CSS均應由這個類名來名稱空間。

• 即使元素沒有被附加到DOM樹上，控制器也應該要工作。對於測試和驗證控制器是否在正確的範圍內，這個方法非常有效。

• 在對子元素髮射事件時，應該是可測試的。

• 在沒有不良反應的任何時候都應該有能力被重新呼叫

• 不要用DOM來儲存狀態——將所有檢視的指定狀態以例項屬性的方式儲存在控制器

　　檢視層

• 除了流控制和輔助功能外，應該減少邏輯性

• 當需要直接渲染時，應該讓所有資料都通過。在當前的域內，所有的資料都應該有效。

　　模型層

• 應該純粹地與資料、運算元據和裝飾資料關聯

• 絕不訪問控制層或檢視層

• 絕對訪問或返回DOM結點

• 在執行時，應該只能訪問或請求其它的模型

• 應該將XHR連線與程式的其餘部分抽象開來

• 應該包含所有資料驗證

　　Router例項

• 儘可能的減少邏輯性

• 不應該知道或訪問DOM

　　全域性狀態

• 你應該使用一個模組系統，不管是CommonJS、AMD、ES6模組,或其它相同的模組

• 永遠不要設定或訪問全域性變數

　　模組

　　原文 blog.sourcing.io