前天那篇blog更多的是講了下數據驅動、模型驅動的大致概念，今天更多的是講數據驅動以及模型驅動在進行系統實現時的方法以及過程。
數據驅動
采用數據驅動進行系統實現時通常采用的是一個這樣的過程，建立數據源(DataSource)，同時根據業務對象模型進行數據庫表設計，在數據庫表設計完成后根據業務場景構成數據集(DataSet)，通常這個時候DataSet本身就是一種業務場景所需的業務數據，在簡單的情況下有可能就是對某張表的操作，復雜的情況下則是對于多張表的操作，在DataSet構成后將此DataSet綁定到頁面即可進行數據的展現了，如需對數據進行增加、編輯、刪除同樣通過DataSet方式來進行，這個過程基本上就是一個基于數據驅動進行系統實現的過程了。
模型驅動
采用模型驅動進行系統實現時通常采用的是一個這樣的過程，根據業務場景建立業務對象，在進行持久時持久業務對象中需要持久的屬性，對于業務場景的實現通過Facade模式對外提供統一接口，此接口通過與持久層進行交互以及操作業務對象(或領域對象)來完成業務場景的實現，而頁面則通過此領域對象或顯示對象來進行數據的展現，如需對數據進行操作按照顯示對象--->Service Facade來完成。
從上面關于實現的過程的描述上來說，會覺得好像模型驅動更為復雜，但模型驅動較之數據驅動的優點我想不用多少，這里更重要的是我覺得是對于數據驅動和模型驅動的一個理解，其實數據驅動同樣是模型驅動，呵呵，數據驅動中的業務對象模型我們可以認為和模型驅動中的業務對象模型一致，其和模型驅動的不同點在于數據驅動采用DataSet的方式來實現業務場景，而模型驅動通常采用Service Facade調用各領域對象來實現業務場景，這里有一點非常明顯，數據驅動只適合一種簡單的業務場景，那就是通過數據關聯或簡單的數據邏輯處理可以來實現的業務場景，而Service Facade其實對于兩者均通用，通過構建類似DataSet的數據關聯或簡單的數據邏輯處理通過和持久層交互即同樣達到了如此的目的，^_^，而且這種方式對于復雜的業務場景同樣可以實現，通過領域對象的交互即可完成，而在DataSet方式中這個步驟是比較棘手的，雖然也可以處理，但會帶來的問題就是重復代碼的增多以及可維護性的降低，其實關鍵的問題就是其沒有形成對象，內聚性不夠強。
我的觀點仍然是數據驅動是一種退化的模型驅動或者說變相的模型驅動，數據驅動中根據業務對象模型進行數據庫表設計的這個過程可以映射為在模型驅動中進行業務對象模型實現的過程，而建立數據集的過程則和模型驅動中的Service Facade頗為相似，只是其Service Facade中的方法比較簡單，至于DataSet綁定到頁面這個過程其實和模型驅動中將領域對象或顯示對象和頁面綁定是相同的概念。
模型驅動思想才是王道，
，需要的僅僅是架構體系中對于數據驅動這種變相的模型驅動也提供一個良好的支持，其實我覺得通過上面的描述已經可以看到要去做出這個支持是非常簡單的一件事，抽象形成通用Service Facade以及考慮如何建立DataSet即完成了這個實現，而且這樣的架構對于模型驅動同樣支持，^_^，何樂而不為，魚和熊掌均可得之(其實就只有熊掌，只是一個可能是肥壯一些的，一個是瘦弱一些的，^_^)。