昨天，Jeffrey Way 發(fā)布了一條推文，他問大家更愿意將其控制器命名為單數(shù)還是復(fù)數(shù)。 我回答我兩種方案都不選，我使用單動作控制器。隨后發(fā)生的是，有的人同意，有的不同意，有的甚至做出了最奇怪的事情。

由于十分強烈的反映，我想寫一篇文章來解釋為什么我愛單行為控制器、還有我為什么覺得它們很美妙。

首先在開始文章之前，我想要說這個東西并不是只有單一的真相。與往常一樣，我想指出的是，一切都歸結(jié)于你的個人喜好。我只能教、建議和指出一些事情，由你來決定是否同意、不同意、接受、學(xué)習(xí)和 / 或調(diào)整。或者都不是。從這篇博客中獲得你想要的，隨心所欲地做讓自己感到舒適的事情吧。

對比 CRUD 和 Domain Modelling

開始前，我們先來想想我們傾向于寫 resourceful 的 CRUD 控制器。我相信很多人會堅持使用這種做法，因為這是 Laravel 中的一個標(biāo)準(zhǔn)做法，文檔中的大多數(shù)示例也是使用這種方法。另外，這或許也是你在各類博客或 app 代碼中經(jīng)?？吹降?。

但是，如果你停下來思考一下，這是編寫它們的最佳方法嗎？是軟件行業(yè)的一般性做法嗎？最近幾年，我在 “領(lǐng)域驅(qū)動設(shè)計”(Domain Driven Design) 等領(lǐng)域投入了大量時間，并且思考軟件如何應(yīng)用于你工作的領(lǐng)域（Domian）以及它轉(zhuǎn)化的過程。當(dāng)您開始考慮模仿您領(lǐng)域中無處不在的語言的術(shù)語和措辭時，您會發(fā)現(xiàn)您的代碼將變得更加清晰明了，更加戳到點子上。（最后這一句話仍值得斟酌、改進）

最后，我相信編寫軟件的本質(zhì)是盡可能地應(yīng)用 domain processes 來讓你的代碼更加易讀和更加可維護。

Resourceful 控制器在這兩個方面做得并不好。首先，它們不易讀，因為您傾向于根據(jù)數(shù)據(jù)來構(gòu)建它們，而不是根據(jù)領(lǐng)域來構(gòu)建它們。這樣的話，你就會丟失上下文對照。你表現(xiàn)了數(shù)據(jù)的處理方式，但卻沒有說明到底發(fā)生什么了，也沒有說明你使用哪個過程進行處理。

第二，你沒有針對可維護性進行優(yōu)化。由于你是根據(jù)數(shù)據(jù)結(jié)構(gòu)來構(gòu)建的，因此你也會跟著耦合進去。實際上，您的領(lǐng)域模型在不斷發(fā)展，數(shù)據(jù)結(jié)構(gòu)也在不斷發(fā)展。如果你的數(shù)據(jù)結(jié)構(gòu)處理著多個過程或領(lǐng)域的多個部分，那你將很難進行調(diào)整。

一個實際的例子

因為理論很無聊，上代碼更加容易解釋，所以我們來看一個實際的例子。

假設(shè)您正在構(gòu)建一個應(yīng)用，它允許用戶去組織事件。您想提供一種創(chuàng)建，更新和刪除這些事件的方法。這是一種非常典型的例子，你會用 CRUD 的方式來考慮實現(xiàn)它。那么，讓我們看看就這樣一個 resourceful 控制器是如何被轉(zhuǎn)換的。

首先我們來看看路由:

Route::get('events', [EventController::class, 'index']); Route::get('events/create', [EventController::class, 'create']); Route::post('events', [EventController::class, 'store']); Route::get('event/{event}', [EventController::class, 'show']); Route::get('events/{event}/edit', [EventController::class, 'edit']); Route::put('events/{event}', [EventController::class, 'update']); Route::destroy('events/{event}', [EventController::class, 'destroy']);

現(xiàn)在對應(yīng)的控制器:

<?php namespace AppHttpControllers; use AppModelsEvent; final class EventController {     public function index()     {         // ...     }     public function create()     {         // ...     }     public function store()     {         // ...     }     public function show(Event $event)     {         // ...     }     public function edit(Event $event)     {         // ...     }     public function update(Event $event)     {         // ...     }     public function destroy(Event $event)     {         // ...     } }

這個 EventController 處理所有的 CRUD 請求，展示事件列表，展示指定的事件，創(chuàng)建一個事件，更新一個現(xiàn)存的事件和刪除一個事件。

來看看 index 方法的細節(jié):

public function index() {     $events = Event::paginate(10);     return view('events.index', compact('events')); }

在這個方法中，我們檢索出事件們，然后交給視圖讓它去展示到一個分頁列表中。 到目前為止都還好。但是你現(xiàn)在想實現(xiàn)一個方法，用不同的頁面去查看過去和即將來的事件。讓我們看看如何在 index 方法中實現(xiàn)它：

public function index(Request $request) {     if ($request->boolean('past')) {         $events = Event::past()->paginate(10);     } elseif ($request->boolean('upcoming')) {         $events = Event::upcoming()->paginate(10);     } else {         $events = Event::paginate(10);     }     return view('events.index', compact('events')); }

呃??！看起來好亂啊。盡管我們已經(jīng)用 Eloquent scopes 來隱藏查詢邏輯，但是還是有很丑的鏈?zhǔn)秸Z句。我們來看看如何用單行為控制器來代替它。

每個單行為控制器只執(zhí)行一件事情，僅僅一件事情。

首先，我們不使用查詢參數(shù)去獲得不同的事件列表，而是使用專用路由去實現(xiàn)它。

Route::get('events', ShowAllEventsController::class); Route::get('events/past', ShowPastEventsController::class); Route::get('events/upcoming', ShowUpcomingEventsController::class);

這個路由比之前的要長一些，但是這個比之前的要更有表達力。你可以一下子辨識出哪一個控制器處理哪一個特定的邏輯。如果你對比一下 URL，你會看到在可讀性上改進了一些：

# Before /events /events?past=true /events?upcoming=true # After /events /events/past /events/upcoming

現(xiàn)在來看其中一個控制器。就看 ShowUpcomingEventsController 這個控制器:

<?php namespace AppHttpControllers; use AppModelsEvent; final class ShowUpcomingEventsController {     public function __invoke()     {         $events = Event::upcoming()->paginate(10);         return view('events.index', compact('events'));     } }

丑陋的 if 語句沒了， and has made way for the same readable three liner we had from our first CRUD controller example. But instead of having all of the other CRUD operations we now have a dedicated controller for a dedicated action.

簡單，易讀，便于維護。

你可能會問自己，這樣做值么，畢竟之前的 if 語句也沒那么壞吧？但是我想向你展示的是你正在為未來的改進做優(yōu)化，并改進維護性。下次你想要對這三個頁面做任何指定改變的時候，你會知道在哪里改，并且不需要艱難地更新一個 if 語句。

當(dāng)然，上面的例子很簡單，我們來看一個更復(fù)雜一點的。我們試試重構(gòu) create 和 store 方法:

public function create() {     return view('events.create'); } public function store(Request $request) {     $data = $request->validate([         'name' => 'required',         'start' => 'required',         'end' => 'required|after:start',     ])     $event = Event::create($data);     return redirect()->route('event.show', $event); }

我們要做的就是把這兩個方法移到專用的控制器，這樣更好地解釋了這些方法做了啥。這些方法更好地服務(wù)于你，比起把它們放在一個叫做 ScheduleNewEventController 的控制器中。我們接著更新這個控制器的路由：

Route::get('events/schedule', [ScheduleNewEventController::class, 'showForm']); Route::post('events/schedule', [ScheduleNewEventController::class, 'schedule']);

我不會向你展示一個確切的控制器，因為它們有和上面的例子一樣，有兩個方法，只不過把 showForm 和 schedule 重新命名為更能表達它們干了啥的名字。即使這個不是單行為控制器，但是方法論是一樣的：把你應(yīng)用中的專用行為（方法）和它對應(yīng)的控制器拆分到一起。

好了，現(xiàn)在你已經(jīng)看了單行為控制器的例子了。你可能會想，這會導(dǎo)致越來越多的文件。但事實上，這個根本就不是問題。文件多又沒啥。有