Larave框架下Contracts契約的決議-有解無憂

本篇文章給大家帶來的內容是關于Larave框架下Contracts契約的決議，有一定的參考價值，有需要的朋友可以參考一下，希望對你有所幫助，

Contracts

Laravel 的契約是一組定義框架提供的核心服務的介面，例如我們在介紹用戶認證的章節中到的用戶看守器契約IllumninateContractsAuthGuard 和用戶提供器契約IlluminateContractsAuthUserProvider

以及框架自帶的App\User模型所實作的IlluminateContractsAuthAuthenticatable契約，

為什么使用契約

通過上面幾個契約的原始碼檔案我們可以看到，Laravel提供的契約是為核心模塊定義的一組interface，Laravel為每個契約都提供了相應的實作類，下表列出了Laravel為上面提到的三個契約提供的實作類，

契約	Laravel內核提供的實作類
IllumninateContractsAuthGuard	IlluminateAuthSessionGuard
IlluminateContractsAuthUserProvider	IlluminateAuthEloquentUserProvider
IlluminateContractsAuthAuthenticatable	IlluminateFoundationAuthAuthenticatable(User Model的父類)

所以在自己開發的專案中，如果Laravel提供的用戶認證系統無法滿足需求，你可以根據需求定義看守器和用戶提供器的實作類，比如我之前做的專案就是用戶認證依賴于公司的員工管理系統的API，所以我就自己寫了看守器和用戶提供器契約的實作類，讓Laravel通過自定義的Guard和UserProvider來完成用戶認證，自定義用戶認證的方法在介紹用戶認證的章節中我們介紹過，讀者可以去翻閱那塊的文章，

所以Laravel為所有的核心功能都定義契約介面的目的就是為了讓開發者能夠根據自己專案的需要自己定義實作類，而對于這些介面的消費者(比如：Controller、或者內核提供的 AuthManager這些)他們不需要關心介面提供的方法具體是怎么實作的，只關心介面的方法能提供什么功能然后去使用這些功能就可以了，我們可以根據需求在必要的時候為介面更換實作類，而消費端不用進行任何改動，

定義和使用契約

上面我們提到的都是Laravel內核提供的契約，在開發大型專案的時候我們也可以自己在專案中定義契約和實作類，你有可能會覺得自帶的Controller、Model兩層就已經足夠你撰寫代碼了，憑空多出來契約和實作類會讓開發變得繁瑣，我們先從一個簡單的例子出發，考慮下面的代碼有什么問題：

class OrderController extends Controller

{

public function getUserOrders()

{

$orders= Order::where('user_id', '=', \Auth::user()->id)->get();

return View::make('order.index', compact('orders'));

}

這段代碼很簡單，但我們要想測驗這段代碼的話就一定會和實際的資料庫發生聯系，也就是說， ORM和這個控制器有著緊耦合，如果不使用Eloquent ORM，不連接到實際資料庫，我們就沒辦法運行或者測驗這段代碼，這段代碼同時也違背了“關注分離”這個軟體設計原則，簡單講：這個控制器知道的太多了，控制器不需要去了解資料是從哪兒來的，只要知道如何訪問就行，控制器也不需要知道這資料是從MySQL或哪兒來的，只需要知道這資料目前是可用的，

Separation Of Concerns 關注分離

Every class should have a single responsibility, and that responsibility should be entirely encapsulated by the class.

每個類都應該只有單一的職責，并且職責里所有的東西都應該由這個類封裝

接下來我們定義一個介面，然后實作該介面

interface OrderRepositoryInterface

{

public function userOrders(User $user);

}

class OrderRepository implements OrderRepositoryInterface

{

public function userOrders(User $user)

{

Order::where('user_id', '=', $user->id)->get();

}

將介面的實作系結到Laravel的服務容器中

1	`App::singleton('OrderRepositoryInterface',` `'OrderRespository');`

然后我們將該介面的實作注入我們的控制器

class UserController extends Controller

{

public function __construct(OrderRepositoryInterface $orderRepository)

{

$this->orders = $orderRespository;

}

public function getUserOrders()

{

$orders = $this->orders->userOrders();

return View::make('order.index', compact('orders'));

}

現在我們的控制器就完全和資料層面無關了，在這里我們的資料可能來自MySQL，MongoDB或者Redis，我們的控制器不知道也不需要知道他們的區別，這樣我們就可以獨立于資料層來測驗Web層了，將來切換存盤實作也會很容易，

鏈接：https://pan.baidu.com/s/1v5gm7n0L7TGyejCmQrMh2g 提取碼：x2p5

免費分享，但是X度限制嚴重，如若鏈接失效點擊鏈接或搜索加群群號518475424，

介面與團隊開發

當你的團隊在開發大型應用時，不同的部分有著不同的開發速度，比如一個開發人員在開發資料層，另一個開發人員在做控制器層，寫控制器的開發者想測驗他的控制器，不過資料層開發較慢沒法同步測驗，那如果兩個開發者能先以interface的方式達成協議，后臺開發的各種類都遵循這種協議，一旦建立了約定，就算約定還沒實作，開發者也可以為這介面寫個“假”實作

class DummyOrderRepository implements OrderRepositoryInterface

{

public function userOrders(User $user)

{

return collect(['Order 1', 'Order 2', 'Order 3']);

}

一旦假實作寫好了，就可以被系結到IoC容器里

1	`App::singleton('OrderRepositoryInterface',` `'DummyOrderRepository');`

然后這個應用的視圖就可以用假資料填充了，接下來一旦后臺開發者寫完了真正的實作代碼，比如叫RedisOrderRepository，那么使用IoC容器切換介面實作，應用就可以輕易地切換到真正的實作上，整個應用就會使用從Redis讀出來的資料了，

介面與測驗

建立好介面約定后也更有利于我們在測驗時進行Mock

public function testIndexActionBindsUsersFromRepository()

{

// Arrange...

$repository = Mockery::mock('OrderRepositoryInterface');

$repository->shouldReceive('userOrders')->once()->andReturn(['order1', 'order2]);

App::instance('OrderRepositoryInterface', $repository);

// Act...

$response = $this->action('GET', 'OrderController@getUserOrders');

// Assert...

$this->assertResponseOk();

$this->assertViewHas('order', ['order1', 'order2']);

}

總結

介面在程式設計階段非常有用，在設計階段與團隊討論完成功能需要制定哪些介面，然后設計出每個介面具體要實作的方法，方法的入參和回傳值這些，每個人就可以按照介面的約定來開發自己的模塊，遇到還沒實作的介面完全可以先定義介面的假實作等到真正的實作開發完成后再進行切換，這樣既降低了軟體程式結構中上層對下層的耦合也能保證各部分的開發進度不會過度依賴其他部分的完成情況，

轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/124128.html

標籤：PHP

上一篇：[PHP] CentOS下搭建下PHP的運行環境

下一篇：laravel框架的中間件middleware的詳解