The Clean Architecture by Uncle Bob

文章
影片

Robert C. Martin在講Clean Architecture。講得非常的棒有空的人最好可以看看影片，他講的非常簡單明瞭，我有空會把他完整講的東西整理一下
重點摘要：UI, Web, DataBase, Framework等東西都只是tools, 或者是details，都是不重要的東西，最後在決定怎麼去實作或者使用。重要的是Use cases也就是Busniess logic。
有空可以看一下1992年Ivar Jacobson所寫的Object Oriented Software Engineering: A Use Case Driven Approach，或者Use case driven相關的書

Repository Pattern

Repository Pattern

一般在設計較為複雜的大型應用程式時，會建議將程式依各部分不同元件的屬件去劃分成不同區塊，方便去撰寫、控管不同區塊的程式。
Microsoft建議可以將程式，粗略分成三層式的架構，如下圖

three-layered-services-application.png

簡單來說：Presentation Layer是用來置放有關於UI相關的程式；Business Layer是處理Presenstaion Layer和Data Layer之前相關的邏輯；Data Layer負責資料相關的儲存、查詢

由上圖可以得知，在Business Layer和Data Layer是具有相依關係的，也就是說一般我們在撰寫程式時，常常會將我們的資料存在資料庫、硬碟或者雲端之中；但是假如將來有一天，程式使用的資料庫系統突然不敷需求，可能要從MySQL換到Oracle，問題是Business Layer和Data Layer的關係是綁定的，原本在Business Layer使用的MySQL API在Oracle上面不存在或者介面長的不一樣，所以開發者要花費大量的工夫去一一檢查、置換程式，會造成有非常大的風險，可能置換完的結果會出錯，勞財勞神。

Repository Pattern就是要來解決這樣的問題。他的架構如下圖表示

repository-pattern.png

就是在Business Layer和Data Layer之間多了一層Repository Pattern層，Business Layer完全不知道他用的Data Layer是用什麼樣的系統。Business Layer要的很簡單，就是他發出的query可以拿到正確的資料，也因此他發出來的query的介面是一致的，只是實際上實做出來的結果是跟不同系統有相關的，MySQL就是用MySQL的介面實作，Oracle就用Oracle。

repository-pattern-detail.png

如此一來，假如真的有一天我們要換Data Layer，query的介面是一樣的，我只需要換不同的實作就好了。

這麼做的好處就是，程式劃分的非常的乾淨，Business Layer只相依於Repository Pattern；Data Layer綁定於Repository Pattern，在測試維護上面，因為只變動實作的部分，我們只需要關心不同實作出來的資料是不是正確的就好，而不需要花費大量的工夫來測試全部的區塊。