【Day-23】改造MVC - Controller(概念篇)

文章同步於it邦

前言

今天要來講講改造MVC的Controller
雖然沒有DDD這種架構如此乾淨，但依然是不少人使用的架構

起因

這就要先講講為甚麼要改造controller
前面介紹了那麼多軟體設計、架構的原則
我們可以清楚知道說將所有Code一拖拉庫往Controller塞，會造成沒有辦法撰寫單元測試
根據單一職責原則，我們就必須要把Controller職責過多的狀況改善

範例

假設我今天有一個會員要註冊的API，我把驗證、登入邏輯全部寫再一起

class MemberController extends Controller
{
    public function store(Request $request)
    {
        // 驗證請求參數
        $validatedData = $request->validate([
            'member_name' => 'required|string|min:1|max:60',
            'member_email' => 'required|string|email|max:255|unique:members', // 確保email在資料庫中唯一
            'member_password' => 'required|string|max:255',
        ]);

        // 在資料庫中建立會員資料
        try {
            $member = Member::create([
                'member_name' => $validatedData['member_name'],
                'member_email' => $validatedData['member_email'],
                'member_password' => $validatedData['member_password'],
            ]);

            // 成功建立資料，回傳201 Created狀態碼
            return response()->json(['message' => '會員資料建立成功'], 201);
        } catch (\Exception $e) {
            // 發生錯誤，回傳錯誤訊息
            return response()->json(['message' => '會員資料建立失敗'], 500);
        }
    }
}

光只是兩個非常基礎的流程就搞到Controller如此大一包了，如果未來還要加入活動，什麼名字裡面有鮭魚就送鮭魚的這種判斷條件也寫進去，那真的是不得了

而且這樣寫也沒有人知道驗證跟資料庫那一層是否正確

拆法

我們先重新定義Controller的職責，不管我的業務邏輯是甚麼，我始終只會讓Controller去取得需要的資訊最後傳給前端
那為了這件是我是必要把責任分擔出去
根據上述的條件，我會如此的拆分我的Controller

也就是說，我的Controller是依賴其他層級的原件，那到時候要修改我就會直接把底下的部分抽換掉就好
在這個狀況下，我也可以針對每一個功能去進行單元測試，清楚的了解哪邊有問題

參考資料

Day 01: 【序】– 架構與設計、代碼、工程師
打造 Laravel 優美架構
DAY6 - 你的 Backend 可以更有彈性一點 - Clean Architecture 概念篇
go-clean-arch