打造 Laravel 優美架構 談可維護性與彈性設計

個人github博客：zgxxx.github.io/

公司項目可能須要對架構進行重建，老大給了我一個視頻讓我學習裏面的思想，看完後以爲收穫很大，主講人對laravel項目各個層次有很清晰的理解，力求作到職責單一分明，提升可維護性。下面是我看完視頻對其內容的大概整理，以及一些本身的看法，有錯誤的請指出。 視頻：www.youtube.com/watch?v=pzY… (有牆各位懂的)

Laravel簡單架構：

簡單的小項目可能會把數據庫查詢，業務邏輯，數據傳給View幾乎全部操做都放在Controller，如何項目後期需求變大，最後Controller會變得很臃腫，難懂，不易維護（一樣，有些會把全部增刪改查，功能類寫在Model，Controller再從Model一個個的拿，致使Model很亂，Model有關聯表的時候可能會引發一些沒必要要的數據庫查詢）

我本身的理解：用美宜佳賣商品給客人來理解，主要Controller是某個加盟商美宜佳門店，View是客人，Model是商品製造工廠（理解有些粗糙）

Repository（商品倉庫）:

跟Eloquent/DB操做相關的，例如增刪改查，直接和數據庫打交道的基礎操做抽出來放在Repository中，repository中文是倉庫，個人理解就是咱們要從Model拿數據，先放在倉庫repository中，統一由倉庫管理分配，發揮倉庫的職責

Service (總部服務平臺):

商業邏輯，不是簡單的查詢數據，而是特定的任務，例如判斷用戶是不是會員，設置用戶權限等等，這些操做建議放在Service，以後Controller再調用它

**我的理解：**因此在Controller和Model/Eloquent中間墊兩層，若是Repository理解爲商品倉庫的話，個人理解Service是相似總部內部的服務平臺，加盟商Controller須要拿商品給客人View，不能直接去食品工廠Model拿，先經過倉庫repository，而後總部服務平臺Service進行打包啊，整理啊，發車啊（各類任務），最後再給到加盟商Controller手裏

Presenter（充值業務）:

一些比較固定，能夠單獨調用的，能夠用Presenter抽出來，不須要讓Model去作，下次修改也單獨修改Presenter就好了， 例如時間戳轉成Y-m-d H:i:s格式，能夠單獨用Presenter處理後用@inject插入到前端模板，而不是把轉化過程寫在模板上面

**我的理解：**因此在Controller和View中間能夠加一層Presenter，個人理解有點相似：美宜佳商戶(Controller)能夠給客人(View)充公交卡，這種小事不須要勞費工廠(Model)

Transformer（快餐小吃人工篩選）:

轉換器，例如在倉庫repository中有一個獲取全部用戶信息的查詢操做：this->user->all(['name','email'])? 這樣另外的地方又要所有字段，這不就衝突了？這時候Transformer就有用了，其實原理是對$this->user->all()得到的數據進行篩選後再輸出，加了個篩選器。

以後要修改結果字段就直接在transform修改便可，固然還能夠額外添加須要的字段：array_set()

**我的理解：**這一塊個人理解就是有些客人須要點一些快餐，例如美宜佳里面的車仔麪呀，烤腸呀，在賣出商品的時候須要根據客人的需求對小吃進行篩選再賣出去，不可能客人指點要一個烤腸，你把店裏所有小吃拿給他，讓他自個去篩選，中間賣出去的時候須要Transformer進行篩選再給出商品

Formatter（包裝）:

主要用於保持API返回格式的一致（使用方法和transform相似）：

我的理解：Formatter這一塊個人理解就是商品包裝，客人買東西，買小吃，你須要對商品先進行包裝，固然這個包裝確定須要保持一致

以上即是我再看完視頻後對其進行總結整理，固然理論的說的容易，實際操做起來還有不少未知的問題，仍是須要後面繼續研究學習。