這篇文章主要講解了“Composer+Git如何創(chuàng)建服務(wù)類庫”，文中的講解內(nèi)容簡單清晰，易于學(xué)習(xí)與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學(xué)習(xí)“Composer+Git如何創(chuàng)建服務(wù)類庫”吧！

莒縣網(wǎng)站建設(shè)公司創(chuàng)新互聯(lián)公司,莒縣網(wǎng)站設(shè)計制作，有大型網(wǎng)站制作公司豐富經(jīng)驗。已為莒縣千余家提供企業(yè)網(wǎng)站建設(shè)服務(wù)。企業(yè)網(wǎng)站搭建\外貿(mào)網(wǎng)站制作要多少錢，請找那個售后服務(wù)好的莒縣做網(wǎng)站的公司定做！

Composer 的修改

創(chuàng)建服務(wù)類庫

首先，我需要把我的 “服務(wù)類庫” 從我的應(yīng)用程序（起名為 xxx/main1）中獨立出來，這個獨立，我不是選擇在應(yīng)用程序中創(chuàng)建一個目錄（事實我想過創(chuàng)建一個諸如 Services 的目錄）。但是，如果和業(yè)務(wù)程序在代碼上耦合起來，我覺得以人的惰性，很難從始至終都控制住自己能堅持不使用應(yīng)用程序中方便的各種函數(shù)。所以我的選擇是在 Git 庫中新創(chuàng)建一個項目，起名為 xxx/mapService 。

composer.json

現(xiàn)在兩個 Git 項目(xxx/main1 和 xxx/mapService)，我在 main1 中的 composer.json 文件中增加下面的語句：

而在 mapService 的 composer.json 如下：

這個配置告訴 main1 項目，mapService 的 Git地址，需要使用的版本。

當然需要注意下面幾點：

• dev-master 意思是直接使用 mapService 的master分支。如果 mapService 有其他的 tag，這里完全可以使用 tag 信息

• repositories 是說明項目的地址

• 我這里的這個服務(wù)是放在我們公司自己搭建的 GitLab 上的

• mapService 下面的 src 文件夾的命名空間為 xxxx\\xxxx\\MapService\\ 并且支持 PSR-4

• mapService 使用了 illuminate/database

最后使用 composer update -vvv 可以把我們需要的 mapService 下載下來放在 vendor 目錄下。

更新修改

我們現(xiàn)在編輯器在 main1 項目中，如果我們有對 mapService 這個項目有進行編輯修改，并且希望合并到 mapService 的 master 分支的化，就直接進入 vender/xxx/mapService 目錄，進行 Git 對應(yīng)的操作。這樣就可以進行直接的代碼修改了。

獨立配置

這種結(jié)構(gòu)的組合方式只是完成了萬里長征的第一步。后續(xù)更為重要的是在編寫這個服務(wù)的時候，我需要時刻記住不使用 main1 的所有東西，這樣才能保持 mapService 的獨立性（獨立性是服務(wù)化的必要條件之一）。比如我第一個遇到的問題就是配置文件需要獨立。

我的實現(xiàn)方式是直接在 mapService 中創(chuàng)建一個 Config 類，這個類中直接寫死配置。

這里一直覺得這個配置文件的實現(xiàn)方式有點挫，因為這樣，這個配置文件就進入到了 Git庫。但是確實沒有想到更好的方案了。Laravel 中有通過實現(xiàn) ServiceProvider 將 Config 創(chuàng)建在 Laravel 的config 文件夾下的方式，但是這種方式僅僅只適用于 Laravel。沒有通用性。在另外一個方向，我想服務(wù)使用哪個數(shù)據(jù)庫這個本身也是服務(wù)的一部分，放在服務(wù)的 Git 庫中貌似也沒有什么。

目錄結(jié)構(gòu)

目錄結(jié)構(gòu)如上

• Configs 提供配置文件

• Contracts 提供接口協(xié)議

• Exceptions 提供異常

• Supports 提供第三方方法或者類庫

• Models 提供對數(shù)據(jù)庫的交互

• Node.php 實現(xiàn)具體的接口

服務(wù)最重要的事情是接口協(xié)議。所以創(chuàng)建一個Contracts文件夾，將提供的服務(wù)接口化。

接口的異常處理盡量使用異常，而不是錯誤碼的方式進行交互。而且這些異常盡量要自定義。這樣，在上層就有了統(tǒng)一處理的可能性。

思考

這個架構(gòu)模式我定位為 PHP 代碼層面服務(wù)化的模式。適用的場景應(yīng)該是：

• 后期計劃服務(wù)化

• 前期人力和思維都希望維持快速開發(fā)的場景

和 Git 的 SubTree 、SubModule 的區(qū)別

其實這三種方式說到底都是將一個項目作為另外一個項目的類庫來使用的。SubTree 和 SubModule 是 Git 的解決方案。而 Composer 是 PHP 語言的解決方案，它除了將某個項目加入到另外一個項目的功能之外，還提供了加入版本，依賴解決等方案。如果你的項目是 PHP 的，那么無疑，使用 Composer 是更優(yōu)的選擇。

后期協(xié)議服務(wù)化

如果后期我的這個 mapService 想要協(xié)議服務(wù)化，那么這個 mapService 項目就可以簡化成為一個SDK，對于上層業(yè)務(wù)邏輯，只需要使用 composer update 進行更新就行。

服務(wù)注冊和發(fā)現(xiàn)

我這里所謂的 “服務(wù)類庫” 確實沒有解決服務(wù)注冊的問題，我無法知道到底有幾個項目使用了我的服務(wù)。這個可能需要額外的流程的工作了。

感謝各位的閱讀，以上就是“Composer+Git如何創(chuàng)建服務(wù)類庫”的內(nèi)容了，經(jīng)過本文的學(xué)習(xí)后，相信大家對Composer+Git如何創(chuàng)建服務(wù)類庫這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是創(chuàng)新互聯(lián)，小編將為大家推送更多相關(guān)知識點的文章，歡迎關(guān)注！