「資料導向」vs. 「服務導向」的開發模式

** 本文同步發表於 FB 社團-軟體設計鮮思維 **

傳統且比較直觀的開發方式係採以表單 (form)畫面為單位、然後連結資料庫直接存取資料,這是屬於相當典型的 Client/Server 2-tier 開發模式。

即使轉移到 Web 採所謂廠商提供的 Web MVC 框架 (如 Java Spring MVC),但那也只是 Web 端的一種技術解決方案 (解決 Web Page 狀態控管問題);然後再使用廠商提供如 Java Spring O-R Mapping 機制 (如使用 Hibernate Framework)連結資料庫,這仍是傳統的 Client/Server,重視以資料為導向 (data-oriented)的開發方式。

「資料導向」的開發方式直覺且簡單,當系統規模小且營運需求並不常變動,這樣是行得通的,而且在系統開發的初期會是相當快速的;但當營運規模大得經常會要求系統快速配合商務運作,「資料導向」的開發模式卻往往耗在所謂的「共用性整合」議題上太多等待時間了,那種有著「剪不斷、理還亂」的感覺,不僅讓人苦惱,也是引起紛爭的主要來源。

事實上,「資料導向」實際上早已悖離了軟體開發的第一個最基本原則:「封裝 (encapsulation)」。過早揭露資料與邏輯的細節,而使得系統的複雜度提升。

採以「使用案例 (use case)」搭配 Enterprise MVC,則是屬於「服務導向 (service-oriented)」的開發模式。

每一個使用案例代表的是使用者對系統的一種期望 (expectation),反之系統就是需要履行可以達成使用者的目標 (goal)。從系統分析的角度而言,這就是一種 「系統功能 (system function)」的分解方式。

每一個系統功能,有它內部需處理的「程序 (procedure)」,反映在使用案例就是需求陳述,從其中找出系統要做的「事」。再來才是針對這些「事 (程序)」實作需要處理的邏輯以及相關資料的存取。

可以發現到,「服務導向」是先釐清大功能 (使用案例)需達成的目標 (goal),再分析需要幾個「程序」才能達成,然後才是談及資料處理的細節。

這也正與人性相符合,「成功學」其中探究的「目標導向」,正是先釐清目標,規劃幾個小目標 (objective),然後再逐一克服過程中的細節,而非一開始就窮究這些細節,而反而導致遭遇困難卻不知變通而停滯不前了。

「服務導向」反映在軟體系統的實作,最佳的搭配就是 Enterprise MVC (Model-View-Control) 框架。

每一個使用案例搭配一個位於中間層的控制物件 (controller),並從需求陳述找出需達成該使用案例的程序,也就是「方法 (method)」,如此可以定義出該控制類別的骨架 (skeleton)。

每一個方法的實作,需要邏輯運算或者存取資料,均可以先落實在控制類別內的程式實作。先把原來可能會分散於 UI 與資料庫的邏輯先全抽離出來,集中到中間層,讓 UI 只專注於「展示 (present)」、資料庫只負責資料的儲存。這種有別於 Client/Server 框架的方式稱為 3-tier (Client/Middleware/Database)責任分權的框架。

3-tier 其實也可以視為就是一種 「大」 的結構設計:先區分出 UI、Middleware、與資料庫系統各自應擔負的責任 (responsibility)。

每一個大塊的結構再各自探究內部的組件 (part),並再逐層細分這些組件更細的責任。如此層次分明,責任明確,系統才不致雜亂無章,因而也得以增進系統彈性/延展性、讓開發與系統維護更有效率,進而提昇系統的再利用性價值。

文章導覽

   

發表迴響

你的電子郵件位址並不會被公開。 必要欄位標記為 *