前陣子參加線上讀書會，聊到 Laravel 5 的 controller 允許開發者使用 method injection

好奇是如何做到的？

今天 trace 了一下，發現此功能寫在 Illuminate\Routing\RouteDependencyResolverTrait 裡面

然後 Illuminate\Routing\ControllerDispatcher 使用了此 trait

並且在此處呼叫

protected function call($instance, $route, $method)
{
    $parameters = $this->resolveClassMethodDependencies(
        $route->parametersWithoutNulls(), $instance, $method
    );

    return $instance->callAction($method, $parameters);
}

這就是 Laravel 5 controller 提供 method injection 的地方。

順帶一提，直接用 closure 的 routing 寫法的話，一樣支援 method injection

它在 Illuminate\Routing\Route 使用了此 trait

並且在此處呼叫

protected function runCallable(Request $request)
{
    $parameters = $this->resolveMethodDependencies(
        $this->parametersWithoutNulls(), new ReflectionFunction($this->action['uses'])
    );

    return call_user_func_array($this->action['uses'], $parameters);
}

前陣子在SO回答了一個問題

http://stackoverflow.com/questions/27341595/contracts-in-laravel-5/29812568

這問題不難，官方文件就有寫。

過幾天，下面的comments接著有網友 amosmos 提問 IoC Container 實作細節的問題。

他的問題考倒我了，完全無法回答。

於是花了幾天讀原始碼，最後終於搞懂了。

跟大家分享一下這個心得，也順便分享下我在過程中，讀原始碼的整套思路。

正文開始

簡單來說，網友 amosmos 的問題如下：

在 Illuminate/Foundation/Application.php 檔，會在 function registerCoreContainerAliases 看到這些：

        $aliases = [
            'app'                  => ['Illuminate\Foundation\Application', 'Illuminate\Contracts\Container\Container', 'Illuminate\Contracts\Foundation\Application'],
            'auth'                 => 'Illuminate\Auth\AuthManager',
            'auth.driver'          => ['Illuminate\Auth\Guard', 'Illuminate\Contracts\Auth\Guard'],
            'auth.password.tokens' => 'Illuminate\Auth\Passwords\TokenRepositoryInterface',
            'blade.compiler'       => 'Illuminate\View\Compilers\BladeCompiler',
            'cache'                => ['Illuminate\Cache\CacheManager', 'Illuminate\Contracts\Cache\Factory'],
            'cache.store'          => ['Illuminate\Cache\Repository', 'Illuminate\Contracts\Cache\Repository'],
            // ...
        ];

讓我們先稱呼’app’、’auth’這些字串為 IoC Container 內的 「key」 好了。

乍看之下，大部份的 service 都在這時候被綁定到 IoC Container內，對應到某個 key。

看起來非常合理，也很漂亮，對吧？Laravel會用到的service都在這時候統一登記好、綁進這IoC Container。

問題來了，在 config/app.php 內，有這個陣列：

    'providers' => [

        /*
         * Laravel Framework Service Providers...
         */
        Illuminate\Foundation\Providers\ArtisanServiceProvider::class,
        Illuminate\Auth\AuthServiceProvider::class,
        Illuminate\Broadcasting\BroadcastServiceProvider::class,
        Illuminate\Bus\BusServiceProvider::class,
        Illuminate\Cache\CacheServiceProvider::class,
        Illuminate\Foundation\Providers\ConsoleSupportServiceProvider::class,
        // ...
    ];

你如果熟悉 Service Provider (下文以SP代稱) 的話，就會知道每個 SP 內必定有 function register，負責綁定service到container。

以CacheServiceProvider來說，會出現這幾行：

    public function register()
    {
        $this->app->singleton('cache', function ($app) {
            return new CacheManager($app);
        });

        //...
    }

問題來了，在上面的 Application.php，已經有這個了：

            'cache'                => ['Illuminate\Cache\CacheManager', 'Illuminate\Contracts\Cache\Factory'],

所以這CacheManager，到底是何時被綁定到 ‘cache’ 這個key上的？

是Application在建構式呼叫registerCoreContainerAliases時綁定的嗎？

還是在某處讀取 config/app.php 的providers時綁定的？

這邊出現了我們的問題一：

Q1: 難道重複綁定了兩次嗎？CacheManager被初始化了兩次？所以是 Laravel 原始碼的瑕疵？

讓我們做個實驗吧，把Application.php裡面這行comment掉：

            //'cache'                => ['Illuminate\Cache\CacheManager', 'Illuminate\Contracts\Cache\Factory'],

接著在cmd輸入

php artisan tinker

很好，跑起來了，至少laravel沒有炸掉。

接著試試cache功能是否還活著？

Cache::store('file')->put('foo', 'this is foo in the cache', 10);

Cache::store('file')->get('foo');
// => "this is foo in the cache"

看起來沒問題！難道真的是Laravel的瑕疵？

接著把 Application.php恢復原狀，然後把CacheServiceProvider的綁定給comment掉：

    public function register()
    {
        /*
        $this->app->singleton('cache', function ($app) {
            return new CacheManager($app);
        });
       */

接著在cmd輸入

php artisan tinker

[ReflectionException]
Class cache does not exist

Laravel炸掉了！根本不能跑！

所以不算是重複綁兩次？

那就出現了我們的問題二：

Q2: 為什麼 Application.php 內的key給comment掉，功能還是正常運作？

反覆翻閱一下 Application.php、Illuminate\Container\Container.php，會發現 function registerCoreContainerAliases 似乎將整串陣列存在container的成員變數$aliases上？

接著尋找讀取config\app.php的地方，會找到 Illuminate\Foundation\Bootstrap\LoadConfiguration.php這檔案，然後發現Illuminate\Foundation\Bootstrap\RegisterProviders.php這檔案，翻閱Application.php和 Illuminate\Foundation\ProviderRepository.php之後，會發現config\app.php內的providers似乎會存在container的成員變數$bindings上？

有一個很簡單的方法去驗證這件事情。

將 Illuminate\Container\Container.php 的 $aliases 與 $bindings 成員變數改成 public，接著 php artisan tinker

$app = App::make('app');

$app->aliases;
=> [
     "Illuminate\Foundation\Application" => "app",
     "Illuminate\Contracts\Container\Container" => "app",
     "Illuminate\Contracts\Foundation\Application" => "app",
     "Illuminate\Auth\AuthManager" => "auth",
     "Illuminate\Auth\Guard" => "auth.driver",
     "Illuminate\Contracts\Auth\Guard" => "auth.driver",
     //...

$app->bindings;
=> [
     //...
     "command.migrate.refresh" => [
       "concrete" => Closure {#236
         class: "Illuminate\Database\MigrationServiceProvider",
         this: Illuminate\Database\MigrationServiceProvider {#230 …},
         file: "/home/howtomakeaturn/projects/modmaj.com/vendor/laravel/framework/src/Illuminate/Database/MigrationServiceProvider.php",
         line: "144 to 146",
       },
       "shared" => true,
     ],
     "command.migrate.install" => [
       "concrete" => Closure {#237
         class: "Illuminate\Database\MigrationServiceProvider",
         this: Illuminate\Database\MigrationServiceProvider {#230 …},
         parameters: [
           "$app" => [],
         ],
         file: "/home/howtomakeaturn/projects/modmaj.com/vendor/laravel/framework/src/Illuminate/Database/MigrationServiceProvider.php",
         line: "168 to 170",
       },
       "shared" => true,
     ],
     // ...

會發現的確是這樣沒錯！

事到如今，我們會發現Q1的問題解決了：Application.php是存在aliases內，而config\app.php是存在bindings內。並沒有重複綁定兩次的問題！而是container實作細節沒搞清楚的問題！

所以真正的問題應該是這個：

Q3: IoC Container內的$aliases跟$bindings分別是什麼？兩者如何互動？

要解決這個問題，必須去讀container最核心的function make部份程式碼。

/**
 * Resolve the given type from the container.
 *
 * @param  string  $abstract
 * @param  array   $parameters
 * @return mixed
 */

// 首先注意到的是，之前我們稱呼’app’、’auth’這些字串為 IoC Container 內的 「key」
// 其實正確名稱是「abstract」 
public function make($abstract, array $parameters = [])
{

    // 這個getAlias的功能如下
    // >>> $app->getAlias('app');
    // => "app"
    // >>> $app->getAlias('Illuminate\Foundation\Application');
    // => "app"    
    $abstract = $this->getAlias($abstract);

    // If an instance of the type is currently being managed as a singleton we'll
    // just return an existing instance instead of instantiating new instances
    // so the developer can keep using the same objects instance every time.

    // 如果是用singleton或是instance方法，應該是會把物件存在instances陣列
    //這地方會檢查abstract是否真的跟物件綁定，是的話就回傳，收工
    if (isset($this->instances[$abstract])) {
        return $this->instances[$abstract];
    }

    // getConcrete內會去查 $this->bindings[$abstract]['concrete']
    // 尋找這abstract對應到的是哪個類別、或是Closure
    $concrete = $this->getConcrete($abstract);

    // 後面一大段省略
}

看到這邊，我們幾乎可以確定$aliases跟$bindings的關係為何了：

我們在使用 App::make($abstract) 時，輸入的abstract，實際上主要是去bindings找對應並叫出來。

而aliases只是紀錄abstract的其他別名而已，舉例如下：

>>> App::make('cache');
=> Illuminate\Cache\CacheManager {#431}

>>> App::make('Illuminate\Cache\CacheManager');
=> Illuminate\Cache\CacheManager {#431}

>>> App::make('Illuminate\Contracts\Cache\Factory');
=> Illuminate\Cache\CacheManager {#431}

還可以再做進一步的測試，將Container的function alias改成public，然後做以下測試：

$app = App::make('app');

$app->bind('greet', function(){ return 'Hello World!'; });

$app->make('greet');
// => "Hello World!"

$app->make('GreetClass');
// ReflectionException with message 'Class GreetClass does not exist'

$app->alias('greet', 'GreetClass');

$app->make('GreetClass');
// => "Hello World!"

所以正式回答Q3的問題：

Service Provider的function register內會去登記到IoC Container的abstract，實際上是存在$bindings或$instances陣列。

而App::make($abstract)實際上也是從這兩個陣列找東西出來用。

$aliases陣列只是存abstract的其他別名，讓 Binding Interfaces To Implementations 成為可能，也允許直接打類別全名進去。

結論

讀Laravel原始碼有幾個小技巧

1. 多用php artisan tinker去跟laravel互動

2. 把一些source code的變數、函數改成public，在tinker硬倒出來觀察

3. 有些東西很難在一天內搞清楚，睡個覺醒來再看通常很有幫助

（完）

現在很多框架都內建active record pattern來幫助開發者建立application。

乍看之下很自然，實際上它卻違反了一大堆傳統的軟體開發知識。

這會讓工程師在學習時陷入下列困惑：

為甚麼一堆書上的原則（principles）、模式（patterns）、手法（practices），都無法在實務上應用？

接著導致一個更嚴重的認知失調：

是我的開發方法不對嗎？還是這些傳統知識全部過時了？

事實上，active record pattern還真的跟傳統開發知識充滿衝突。

為了點出那些衝突，這篇文章會從傳統開發知識的角度，對active record pattern提出多項批評。

什麼是Active record pattern？

從Rails的ActiveRecord，到Laravel的Eloquent，許多框架都內建active record pattern。

各框架對active record pattern的實作都很華麗。除了直接操作資料庫、充當domain object的功能之外，還提供relationships、自動更新created_at/updated_at欄位等等多種功能。

一般認為active record pattern這個名字由Martin Fowler所發明。

根據他的定義，一旦類別同時處理兩件事情：

* data access logic（處理資料庫相關操作）
* domain logic（處理app的商業邏輯）

就算是實作了active record pattern（下文簡稱AR）。其他華麗的功能都是框架額外提供的。

AR會讓物件同時「提供資料給別人用」與「提供行為給別人呼叫」。

正是因為這點，就傳統開發知識來看，至少可以對AR做出13種批評。

下面會將這些批評分成3種層面來看，然後一一列舉它們：

* 原則層面（Principles）
* 模式層面（Patterns）
* 手法層面（Practices）

（注意：許多批評其實是指同一件事，只是換個層面，或是換個方法描述而已。）

原則層面 （Principles）

1. 違反物件導向（OOP）精神

物件應該將資料對外隱藏，將行為對外開放（hidden data, expose behavior）。

而承載資料的資料結構會將資料對外開放，並且不具有行為（expose data, no behavior）。

AR物件因為同時身兼兩者，導致你從根本上面臨矛盾。

你永遠抓不清分際何在：該讓它所有properties都對外隱藏嗎？還是讓它一個method都沒有？分別該做到什麼程度呢？

// Should I do it this way?
$totalPrice = $order->price + $order->tax;

// Should I do it this way?
$totalPrice = $order->getTotalPrice();

2. 違反Single Responsibility Principle

AR負責了data access logic，導致資料庫schema一改，程式碼必須跟著修改。

AR負責了domain logic，導致app的商業邏輯一改，程式碼必須跟著修改。

OOP知名五大原則SOLID中的SRP被AR直接打破：一個類別應該因為且只因為一個理由而修改。

3. 違反「Tell, don’t ask.」原則

「Tell, don’t ask.」原則指引大家OOP開發應該「告訴物件去做什麼」而不應該「跟物件拿資料出來操作」。

偏偏AR物件是如此方便易用，你幾乎一定會從外部直接取用它的資料。

// This may appear in controllers or service objects.
$totalPrice = $oder->price + $order->tax;

if ($totalPrice > 1000) {
    //...
}

4. 導致Database Oriented Development

應該圍繞著產品本身領域知識去開發的domain driven/business oriented開發方法，變成以database為中心在開發。

開發者在開發過程中，不再對領域知識念茲在茲，而是滿腦子想著database schema。

如果使用的Active Record Pattern甚至實作了toJson這類的函式來幫你把entity內容轉成JSON格式的話，下場就更誇張了：連front-end的開發人員都得跟著滿腦子database schema。前後端分離程度更低。

5. 導致測試時碰到資料庫

傳統上會說測試時應該只測商業邏輯，別碰資料庫，因為碰到資料庫會跑很慢。而且兩者應該分開來測。

但是用了AR會讓測試很難不碰到資料庫。

框架甚至直接提供fixtures、Model Factories來協助這件事，毫不避諱。

模式層面（Patterns）

6. 無法用Constructor Injection

你無法實作這個dependency injection模式來設計類別：

// You can't do this with AR.
$order= new Order(new ComponentA(), new ComponentB());

因為你的建構式被拿來處理data access logic，因而放棄domain logic了。

7. 導致God object

建出來的entity，會很容易把code一直往裡面放，最後變成上千行、負責一堆功能的God object：

$order->iCanDoThis();
$order->iCanDoThat();
$order->iCanDoEverything();

也就是Rails社群流傳的「Fat model, skinny controller」。

8. 導致「貧血的領域模型」（Anemic Domain Model ）

如果你為了避免entity內含過多商業邏輯而將code抽離到別的地方（例如：做了一堆service objects），那很容易變成相反的狀況：entity本身幾乎不含什麼code。

例如這樣：

// The entity now can't do anything.
// So anemic, so poor.
/* 
$order->iCanDoThis();
$order->iCanDoThat();
$order->iCanDoEverything();
*/

// They are all in the services instead.
$service = new DoThisService();

$service->handle($order);

9. 做不出Rich Domain Model

理想狀況是隨著app的商業邏輯越變越複雜，你的domain model會因為各種分工（由多個物件來對外負責各種behavior）而越變越豐富，最後成為漂亮的rich domain model。

非常遺憾的，因為使用了AR的關係，類別的設計被綁死在schema上，因此你很難做出rich domain model。

你要嘛會做出God object，要嘛會做出Anemic domain model。

也許會有人嘗試將data access logic與domain logic分離來克服…

奉勸千萬別這麼做：根本是放棄AR的優點去硬搞，最後變成四不像。

10. 質變的Repository Pattern

將CRUD操作（persistence logic、query logic）封裝的經典模式repository pattern，因為AR而產生質變。

舉例來說，你可能看過有人這樣設計repository class：

class OrderRepository
{
    public function save($order)
    {
        $order->save();
    }

    // blah blah
}

接著將repository用dependency injection放進controller或是service object內。

乍看之下沒問題：確實因此可以在測試時抽換repository object成測試專用的object。

但應該「負責persistence logic」的repository，實際上居然只是叫參數物件自己save自己。

這可稱不上優雅。

質變後的repository退化成只負責查詢功能的query object。

11. 質變的Domain Driven Design

Eric Evans寫的Domain-Driven Design一書教導了一種圍繞領域知識的軟體開發方法。

很悲慘的，如果你用了AR，這本書你將很難看得懂，也很難應用。

DDD從最基本的Repository Pattern就已因AR導致質變（參考10.），再加上entity間的關係通常會被AR直接根據schema建好，Aggregate也變得無法封住內部物件，更不用說domain model根本建不好了（參考9.）。

手法層面（Practices）

12. 濫用public properties

OOP課本翻沒幾頁就會提到getter/setter的觀念，並且反對直接把properties設成public。

AR因為同時負責data access logic，很自然會讓人直接對properties操作：

$order->price = 1000;
$order->is_sold = true;

13. Atomic operation困境

為了確保Database內的資料正確性，有時你需要用到lock機制或是transaction機制。

試問下列這兩行code該放哪呢？

LOCK TABLES orders WRITE, items WRITE, users WRITE

與

UNLOCK TABLES

放在entity的話，代表Order/Item/User其中一個類別會直接操作其餘兩個類別 => 容易導致god object。

不放在entity的話，就必須放在外部（例如service object或controller） => SQL語法不再被封裝在底層，也不被封裝在entity內，而外洩到更上層了。

結論

Active Record Pattern方便、快速開發的特性，讓它具有非常高的商業價值。

這也是Rails之後一直到Laravel等等各大框架都實作它的原因。

愛用Active record pattern跟反對active record pattern的人常常有所爭論，幾乎成了現代開發vs傳統開發方法的戰爭（例一、例二）。

使用它來開發沒什麼問題，但千萬要留心它與哪些傳統開發知識有衝突。

享受它的優點，理解它的缺點，才能在現代和傳統開發知識的衝突上，找到屬於自己的平衡點。

（完）

下面是我在公司新開發的一個討論plugin。歡迎用它來反映您對AR的看法。

順帶一提，server-side是用Laravel 5所寫成：背後的Eloquent，正是實作active record pattern。

(Photo via Don McCullough, CC licensed.)