文章同步於blog

前言

這次要來介紹的是MVC架構，以及在實作上MVC架構需要特別注意的地方
還有甚麼情況下適合用MVC架構

而這些會更傾向以實務上的角度來做說明

介紹

MVC架構是一種相對於大雜燴的方式，更加將職責分離的一種設計模式
這種設計模式，提供了良好的可測試性(Testability)，這使得我們可以更好的撰寫單元測試

而MVC三個字母各代表不同意思

M - Model

M代表Model，通常負責與資料存取有關的操作，通常會和ORM做搭配
以Laravel為例子:

use App\Models\User;  

$user_group = User::get();

我使用我定義好的model + ORM 去取得所有 User 的資料
我甚至可以在model裡面定義各種回傳格式，而不需要透過ORM，例如:

<?php

namespace App;

use Illuminate\Database\Eloquent\Model;

class User extends Model
{
    protected $fillable = ['name', 'email', 'password'];
    
    protected $hidden = ['password'];
}

透過$fillable來決定誰可以被更改以及使用$hidden來決定什麼欄位自動隱藏，而不需要每次都額外撰寫Select()

V - View

V代表View，指的是畫面上的顯示，Controller將包好的資料交給view顯示

但我想這個放到現在是對於後端來說最不重要的，因為view對於MVC來說已經不是必須了，目前在前後端分離的趨勢下，後端更只會負責Model和Controller的部分

C - Controller

C代表Controller，也就是控制應用程式的流程，這通常是最雜亂的一層
當我們把所有Controller全部擠在一起，就會導致整個Controller難以測試
例如：登入的流程需要，驗證、更改使用者狀態、核發access token、包裝API所需要的回傳格式
上方就有至少4個層面需要撰寫，光是簡單的一個登入就這樣，如果還把它寫成一包
我想以後應該會直接吐血

在第一間公司的時候，當時年少懵懂無知，我還處於一個只會把Controller變成大雜燴不寫單元測試的小荷包蛋(知道我要講甚麼就自己轉換XD)
當時我們光一個Controller就寫了快1000多行，混雜著各種邏輯，當年其實就在想，這樣寫以後要怎麼改阿。
直到我接觸了clean code等著作，我才明白，以前的我都在創造職缺麻煩，雖然前輩也是寫在一起的?!

在幾天之後，講完clean architecture，就會使用Laravel來講解如何將Controller拆解成我們所需要的部分就好
今天先賣個關子

專案適合用MVC嗎

基本上到了現代，MVC框架基本上適用於全部大小的專案開發了，小型的也無所謂
現代的MVC專案基本上都可以快速建立、產出、交付
以我自身的經驗來說，目前有幾個小型專案用MVC都可以用MVC框架來實現

不過!!!，還是要看框架本身對於需求是否符合，如果是大型專案又要團隊協作要使用Laravel我反而不建議，PHP本身對於團隊協作比較沒有嚴謹的規範。

這個問題基本上MVC框架一定適合各種大中小型專案開發。

結語

竟然都講到架構面的部分了，明天就要來講講clean architecture這本書了

參考資料

MVC WIKI