摘要:的契約是一組定義框架提供的核心服務(wù)的接口,例如我們?cè)诮榻B用戶認(rèn)證的章節(jié)中到的用戶看守器契約和用戶提供器契約以及框架自帶的模型所實(shí)現(xiàn)的契約。接口與團(tuán)隊(duì)開(kāi)發(fā)當(dāng)你的團(tuán)隊(duì)在開(kāi)發(fā)大型應(yīng)用時(shí),不同的部分有著不同的開(kāi)發(fā)速度。
Contracts
Laravel 的契約是一組定義框架提供的核心服務(wù)的接口, 例如我們?cè)诮榻B用戶認(rèn)證的章節(jié)中到的用戶看守器契約IllumninateContractsAuthGuard 和用戶提供器契約IlluminateContractsAuthUserProvider
以及框架自帶的AppUser模型所實(shí)現(xiàn)的IlluminateContractsAuthAuthenticatable契約。
為什么使用契約通過(guò)上面幾個(gè)契約的源碼文件我們可以看到,Laravel提供的契約是為核心模塊定義的一組interface。Laravel為每個(gè)契約都提供了相應(yīng)的實(shí)現(xiàn)類,下表列出了Laravel為上面提到的三個(gè)契約提供的實(shí)現(xiàn)類。
契約 | Laravel內(nèi)核提供的實(shí)現(xiàn)類 |
---|---|
IllumninateContractsAuthGuard | IlluminateAuthSessionGuard |
IlluminateContractsAuthUserProvider | IlluminateAuthEloquentUserProvider |
IlluminateContractsAuthAuthenticatable | IlluminateFoundationAuthAuthenticatable(User Model的父類) |
所以在自己開(kāi)發(fā)的項(xiàng)目中,如果Laravel提供的用戶認(rèn)證系統(tǒng)無(wú)法滿足需求,你可以根據(jù)需求定義看守器和用戶提供器的實(shí)現(xiàn)類,比如我之前做的項(xiàng)目就是用戶認(rèn)證依賴于公司的員工管理系統(tǒng)的API,所以我就自己寫了看守器和用戶提供器契約的實(shí)現(xiàn)類,讓Laravel通過(guò)自定義的Guard和UserProvider來(lái)完成用戶認(rèn)證。自定義用戶認(rèn)證的方法在介紹用戶認(rèn)證的章節(jié)中我們介紹過(guò),讀者可以去翻閱那塊的文章。
所以Laravel為所有的核心功能都定義契約接口的目的就是為了讓開(kāi)發(fā)者能夠根據(jù)自己項(xiàng)目的需要自己定義實(shí)現(xiàn)類,而對(duì)于這些接口的消費(fèi)者(比如:Controller、或者內(nèi)核提供的 AuthManager這些)他們不需要關(guān)心接口提供的方法具體是怎么實(shí)現(xiàn)的, 只關(guān)心接口的方法能提供什么功能然后去使用這些功能就可以了,我們可以根據(jù)需求在必要的時(shí)候?yàn)榻涌诟鼡Q實(shí)現(xiàn)類,而消費(fèi)端不用進(jìn)行任何改動(dòng)。
定義和使用契約上面我們提到的都是Laravel內(nèi)核提供的契約, 在開(kāi)發(fā)大型項(xiàng)目的時(shí)候我們也可以自己在項(xiàng)目中定義契約和實(shí)現(xiàn)類,你有可能會(huì)覺(jué)得自帶的Controller、Model兩層就已經(jīng)足夠你編寫代碼了,憑空多出來(lái)契約和實(shí)現(xiàn)類會(huì)讓開(kāi)發(fā)變得繁瑣。我們先從一個(gè)簡(jiǎn)單的例子出發(fā),考慮下面的代碼有什么問(wèn)題:
class OrderController extends Controller { public function getUserOrders() { $orders= Order::where("user_id", "=", Auth::user()->id)->get(); return View::make("order.index", compact("orders")); } }
這段代碼很簡(jiǎn)單,但我們要想測(cè)試這段代碼的話就一定會(huì)和實(shí)際的數(shù)據(jù)庫(kù)發(fā)生聯(lián)系。也就是說(shuō), ORM和這個(gè)控制器有著緊耦合。如果不使用Eloquent ORM,不連接到實(shí)際數(shù)據(jù)庫(kù),我們就沒(méi)辦法運(yùn)行或者測(cè)試這段代碼。這段代碼同時(shí)也違背了“關(guān)注分離”這個(gè)軟件設(shè)計(jì)原則。簡(jiǎn)單講:這個(gè)控制器知道的太多了。 控制器不需要去了解數(shù)據(jù)是從哪兒來(lái)的,只要知道如何訪問(wèn)就行。控制器也不需要知道這數(shù)據(jù)是從MySQL或哪兒來(lái)的,只需要知道這數(shù)據(jù)目前是可用的。
Separation Of Concerns 關(guān)注分離Every class should have a single responsibility, and that responsibility should be entirely encapsulated by the class.
每個(gè)類都應(yīng)該只有單一的職責(zé),并且職責(zé)里所有的東西都應(yīng)該由這個(gè)類封裝
接下來(lái)我們定義一個(gè)接口,然后實(shí)現(xiàn)該接口
interface OrderRepositoryInterface { public function userOrders(User $user); } class OrderRepository implements OrderRepositoryInterface { public function userOrders(User $user) { Order::where("user_id", "=", $user->id)->get(); } }
將接口的實(shí)現(xiàn)綁定到Laravel的服務(wù)容器中
App::singleton("OrderRepositoryInterface", "OrderRespository");
然后我們將該接口的實(shí)現(xiàn)注入我們的控制器
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")); } }
現(xiàn)在我們的控制器就完全和數(shù)據(jù)層面無(wú)關(guān)了。在這里我們的數(shù)據(jù)可能來(lái)自MySQL,MongoDB或者Redis。我們的控制器不知道也不需要知道他們的區(qū)別。這樣我們就可以獨(dú)立于數(shù)據(jù)層來(lái)測(cè)試Web層了,將來(lái)切換存儲(chǔ)實(shí)現(xiàn)也會(huì)很容易。
接口與團(tuán)隊(duì)開(kāi)發(fā)當(dāng)你的團(tuán)隊(duì)在開(kāi)發(fā)大型應(yīng)用時(shí),不同的部分有著不同的開(kāi)發(fā)速度。比如一個(gè)開(kāi)發(fā)人員在開(kāi)發(fā)數(shù)據(jù)層,另一個(gè)開(kāi)發(fā)人員在做控制器層。寫控制器的開(kāi)發(fā)者想測(cè)試他的控制器,不過(guò)數(shù)據(jù)層開(kāi)發(fā)較慢沒(méi)法同步測(cè)試。那如果兩個(gè)開(kāi)發(fā)者能先以interface的方式達(dá)成協(xié)議,后臺(tái)開(kāi)發(fā)的各種類都遵循這種協(xié)議。一旦建立了約定,就算約定還沒(méi)實(shí)現(xiàn),開(kāi)發(fā)者也可以為這接口寫個(gè)“假”實(shí)現(xiàn)
class DummyOrderRepository implements OrderRepositoryInterface { public function userOrders(User $user) { return collect(["Order 1", "Order 2", "Order 3"]); } }
一旦假實(shí)現(xiàn)寫好了,就可以被綁定到IoC容器里
App::singleton("OrderRepositoryInterface", "DummyOrderRepository");
然后這個(gè)應(yīng)用的視圖就可以用假數(shù)據(jù)填充了。接下來(lái)一旦后臺(tái)開(kāi)發(fā)者寫完了真正的實(shí)現(xiàn)代碼,比如叫RedisOrderRepository。那么使用IoC容器切換接口實(shí)現(xiàn),應(yīng)用就可以輕易地切換到真正的實(shí)現(xiàn)上,整個(gè)應(yīng)用就會(huì)使用從Redis讀出來(lái)的數(shù)據(jù)了。
接口與測(cè)試建立好接口約定后也更有利于我們?cè)跍y(cè)試時(shí)進(jìn)行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"]); }總結(jié)
接口在程序設(shè)計(jì)階段非常有用,在設(shè)計(jì)階段與團(tuán)隊(duì)討論完成功能需要制定哪些接口,然后設(shè)計(jì)出每個(gè)接口具體要實(shí)現(xiàn)的方法,方法的入?yún)⒑头祷刂颠@些,每個(gè)人就可以按照接口的約定來(lái)開(kāi)發(fā)自己的模塊,遇到還沒(méi)實(shí)現(xiàn)的接口完全可以先定義接口的假實(shí)現(xiàn)等到真正的實(shí)現(xiàn)開(kāi)發(fā)完成后再進(jìn)行切換,這樣既降低了軟件程序結(jié)構(gòu)中上層對(duì)下層的耦合也能保證各部分的開(kāi)發(fā)進(jìn)度不會(huì)過(guò)度依賴其他部分的完成情況。
本文已經(jīng)收錄在系列文章Laravel源碼學(xué)習(xí)里,歡迎訪問(wèn)閱讀。
文章版權(quán)歸作者所有,未經(jīng)允許請(qǐng)勿轉(zhuǎn)載,若此文章存在違規(guī)行為,您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請(qǐng)注明本文地址:http://specialneedsforspecialkids.com/yun/29458.html
摘要:看起來(lái)很麻煩是吧,完全可以封裝一個(gè)函數(shù),直接調(diào)用就可以了,沒(méi)有必要自定義服務(wù)提供者創(chuàng)建契約。將自定義的服務(wù)提供者做如下修改修改了契約的綁定,所有使用契約進(jìn)行依賴注入的實(shí)例,都會(huì)由實(shí)例切換到實(shí)例。 導(dǎo)語(yǔ) laravel 的服務(wù)提供者,是框架的核心,提供了路由、日志、緩存等功能。這里要實(shí)現(xiàn)的需求是使用第三方 API 獲取天氣情況,涉及到服務(wù)提供者、契約、依賴注入等方面。相關(guān)內(nèi)容可以通過(guò)下方...
摘要:過(guò)去一年時(shí)間寫了多篇文章來(lái)探討了我認(rèn)為的框架最核心部分的設(shè)計(jì)思路代碼實(shí)現(xiàn)。為了大家閱讀方便,我把這些源碼學(xué)習(xí)的文章匯總到這里。數(shù)據(jù)庫(kù)算法和數(shù)據(jù)結(jié)構(gòu)這些都是編程的內(nèi)功,只有內(nèi)功深厚了才能解決遇到的復(fù)雜問(wèn)題。 過(guò)去一年時(shí)間寫了20多篇文章來(lái)探討了我認(rèn)為的Larave框架最核心部分的設(shè)計(jì)思路、代碼實(shí)現(xiàn)。通過(guò)更新文章自己在軟件設(shè)計(jì)、文字表達(dá)方面都有所提高,在剛開(kāi)始決定寫Laravel源碼分析地...
摘要:的核心概念包括服務(wù)容器服務(wù)提供者門面契約。所有服務(wù)提供者都需要繼承類。可以為服務(wù)提供者的方法設(shè)置類型提示。方法將在所有其他服務(wù)提供者均已注冊(cè)之后調(diào)用。同樣會(huì)整理成思維導(dǎo)圖的形式以方便記憶與回顧。 showImg(https://segmentfault.com/img/remote/1460000010771201); Laravel 的核心概念包括:服務(wù)容器、服務(wù)提供者、門面(Fac...
摘要:前言年底了不太忙,最近一段時(shí)間也一直在研究,就想寫篇關(guān)于比較深一點(diǎn)的教程系列啥的,于是就找到站長(zhǎng)給開(kāi)了寫教程的渠道。優(yōu)點(diǎn)的就是為藝術(shù)家創(chuàng)造的框架,它也是工程化的趨勢(shì)。項(xiàng)目維護(hù)方便也是事實(shí)。如果有遇到問(wèn)題可以直接在教程下面留言。 前言 年底了不太忙,最近一段時(shí)間也一直在研究laravel,就想寫篇關(guān)于laravel比較深一點(diǎn)的教程系列啥的,于是就找到站長(zhǎng)給開(kāi)了寫教程的渠道。由于第一次寫,...
摘要:外觀模式定義了一個(gè)高層接口,這個(gè)接口使得這一子系統(tǒng)更加容易使用。將使用者與子系統(tǒng)從直接耦合,轉(zhuǎn)變成由外觀類提供統(tǒng)一的接口給使用者使用,以降低客戶端與子系統(tǒng)之間的耦合度。接下來(lái)將深入分析外觀服務(wù)的加載過(guò)程。引導(dǎo)程序?qū)⒃谔幚碚?qǐng)求是完成引導(dǎo)啟動(dòng)。 本文首發(fā)于 深入淺出 Laravel 的 Facade 外觀系統(tǒng),轉(zhuǎn)載請(qǐng)注明出處。 今天我們將學(xué)習(xí) Laravel 核心架構(gòu)中的另一個(gè)主題「Fac...
閱讀 3247·2021-09-22 15:58
閱讀 1717·2019-08-30 14:17
閱讀 1716·2019-08-28 18:05
閱讀 1505·2019-08-26 13:33
閱讀 683·2019-08-26 12:20
閱讀 606·2019-08-26 12:18
閱讀 3192·2019-08-26 11:59
閱讀 1401·2019-08-26 10:36