Clean Architecture: 關於在 MVC 裡使用 Presenter 解決 Use Case 與 UI 的相依問題

圖（一）、LOGO: 基於 Clean Architecture 改畫製的 3D 立體圖形

前言
其實，我應該不止一次討論過這個主題，關於 Clean Architecture 的 Plug-In 的軟件架構，在〔軟體開發之路〕或先前所開的實體課程〔跨平台的 Web API Framework 框架設計〕中討論過、也實際帶著學生實作過這樣的架構。

何謂插件式的軟件架構？

圖（二）、從裝置定義 IDevice 介面來演示 Plug-In 插件式軟件架構

如上圖中，不管是 Quantum 硬碟 還是 Pioneer DVD 都是透過 IDevice 介面來實現硬碟 IHardDisk 的主要功能 或者是 透過 IDVDDeive 來定義 Pioneer 光碟機必備的功能，然而最好能夠透過 DI 注入實作，所以系統的靈活度非常高，組件頂多對介面相依，實作輕易的被抽換。

或者是利用 AOP 模式賦予驗證機制或使用匿名存取，優點也是可抽換性非常高，異動原有功能也不須異動到原有的程式碼。

圖（三）、透過 AOP 賦予驗證機制

先前，我在曾在軟體開發之路裡 PO 過關於在 Clean Architecture 的圖形中，在架構圖的右下角的 Use Case Output Port/Use Case Input Port 到底指的是什麼？而且事後並不只一次也有其他的學員或朋友問我相同的問題，而這其實可由 MVP／MVVM 來講起，為什麼呢？

圖（四）、The Clean Architecture

這其實可由 MVP／MVVM 來講起，為什麼呢？因為在 Clean Architecture 或是更早期的【洋蔥式架構】或【六腳架構】都是由外圈而內相依，內圈可獨立存在。

但問題來了，如果你用 MVC 或是 MVVM 來實現 Clean Architecture 軟體架構的時候，雖然 MVC 本身職責分離，由 Controller 負責協調 View 所需要的 Data，但 View 與 Model 仍然有某種相依性程度在，也就是說，仍然有可能因為 View 的改變而牽連 Model 必須跟著改變，而這違背 Clean Architecture 原本的精神。

好....那所以，該怎麼辦呢？就是在 View 與 (Model/Use Case) 之間，加上一個 Presenter，View 呈現所需要的資料透過一個端口 input Port 作為 View 輸入資料的端口，Use Case 也公開一個端口讓 Presenter 拿取資料，其實這個端口在實作上它就是一個 interface，說穿了就是 (Dependency Inversion Principle, DIP) 的概念而已，這也是後來演化出來的 (Model View Presenter, MVP)，所以最理想的狀態是，Entity/Use Case 只對類似 IPresenter 的介面相依，由實作 IPresenter 的實體來決定要拿哪一個 Model 的資料，也決定要回傳去給哪一個 View，這就是圖上面 Controller 有一條線 使用(use) 〔Use Case Input Port〕與、Presenter 一般化(Genelization)〔Use Case Output Port〕的用意。

參考資料：

https://softwareengineering.stackexchange.com/questions/357052/clean-architecture-use-case-containing-the-presenter-or-returning-data