批處理

　　在多年以前，計算機程式通常是以批處理的模式執行。所謂批處理，就是開發者事先寫好一些程式碼，再將這些程式碼一次執行。這種處理方式有點類似於通過HTML程式碼直接編寫的網頁。瀏覽器只是將HTML程式碼逐行解析，並顯示在瀏覽器視窗。
　　後來，在批處理模式中，開發者可以加入一些特定的程式碼，在程式批處理期間，可以停下來等待使用者輸入一些資訊，並根據使用者輸入的資訊來判斷和執行某個程式分支，這就使程式有了初步的互動性。
　　隨著滑鼠、觸控式螢幕等裝置的出現，批處理時代就逐漸遠去，取而代之的是事件驅動的時代。當然，批處理也還能使用，只是使用的範圍和頻率比事件驅動要少得多。以滑鼠為例，在事件驅動中，使用者可以使用滑鼠單擊等方式進行操作，程式則根據滑鼠指標的位置以及單擊的方式進行響應。JavaScript使用的就是這種事件驅動的程式設計方式。

事件驅動

　　JS是事件驅動（Event Driver）的程式語言。Dom元素上的事件繫結是用來驅動業務邏輯的主要手段。JS中的事件流分為兩種：1.事件冒泡，2.事件捕獲。事件冒泡個人的簡單理解就是從確定到不確定，從小的元素到最後的document，事件捕獲則恰巧相反，它是從不確定到確定，從大到小。
　　事件在實際的業務開發裡面十分的重要，它不僅僅是業務邏輯的推動者也是與物件互動的入口。每個事件都會有一個event物件，物件裡面包含了各種你所想得到的資訊，一般來說我們實際裡面需要的是繫結事件的這個dom元素本身，此時通過e.target就可以得到觸發事件的元素本身了。
　　在實際開發裡面，我們將會用兩種事件繫結的形式，一是事件的繫結，它會直接繫結到具體的元素，只有這個元素的事件被觸發的時候，事件才會進行，具體的程式碼如下（jquery）：

$('#id').click(function(){
    alert("hello");
});

　　這段程式碼為一個id為id的dom元素綁定了一個click事件，當dom元素被點選的事件，將會觸發裡面的方法彈出一個內容為“hello”的彈出框。這種普通新增事件到具體的元素，當元素在頁面上是唯一不變，或者一直存在的時候是可以用的，但是如果一個元素的動態生成的，同時又有多個，那麼普通新增事件就不可以，因為最下面的事件會覆蓋上面的事件。因此我們此時需要的是事件繫結方式新增事件：

$('#id').on('click', '.class', function(){
    alert("hello"
 
);
});

　　個人感覺這種方式的好處就是直觀，頁面做任何改變全交由JS處理，先幹什麼後幹什麼都由自己一手程式碼操控全場。
　　但是，大型專案裡，程式碼編寫的成本和維護的成本都很高。對程式碼規範的要求高，對抽象的要求高，尤其是抽象程度，全賴個人程式設計水平，抽象程度低的話，冗長的程式碼根本不想多看一眼。這大概就是為啥專案裡有一個程式碼寫的爛的人在，程式碼就會越來越爛的原因。

資料驅動

　　資料驅動應該是從flux/redux + react這種模式開始流行的。
　　資料驅動的前提是事先將DOM與資料繫結，像vue這種就是依賴defineProperties, setter, getter將一個vue物件與一個DOM節點模板關聯起來，這個DOM節點裡所有子節點、所有節點屬性，全都可以和vue物件中的data繫結，做到data中某個屬性值變化時，相應DOM節點中對應的某個屬性就變化。
　　如果需求簡單還比較好解決，每個模組中自己解決自己的邏輯，解耦的非常清晰。父子之間的關係也非常明確。但如果需求分析如下圖：
　　
　　可見，對於複雜的互動，或者模組間關係複雜時，這種依賴父子關係的通訊，是一個很大的障礙。
　　但是我們怎麼辦，拒絕模組化開發嗎？那樣頁面設計起來耦合度更大，更加不可維護。
　　首先一點，模組化開發是一個不可逆的趨勢，然而在這種趨勢下，解決模組化通訊是一個非常重要的點。
　　看看上面那個例子如果加上資料驅動的設計思想。
　　
　　重點在於，當互動邏輯不斷增加時，這個關係鏈條依然不會增加，因為模組只和model裡面對於的資料相關聯。
　　當然，這種模式也無法去省略複雜的業務邏輯，只是業務邏輯全部都會聚集在model中。可以理解為頁面上所有的操作都是對資料的操作。然後每個模組只需要監聽關注的資料改變即可，這個監聽關係就是圖中唯一的一條關係線。
　　換一個理解，我們將直接的模組和模組直接的耦合關係全部轉移到了資料中去體現。而資料的維護是遠遠比模組更好維護的。