這篇文章主要講解了“web開發中大型項目該怎么分層架構”，文中的講解內容簡單清晰，易于學習與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學習“web開發中大型項目該怎么分層架構”吧！

專業領域包括成都做網站、成都網站設計、電子商務商城網站建設、微信營銷、系統平臺開發， 與其他網站設計及系統開發公司不同，創新互聯的整合解決方案結合了幫做網絡品牌建設經驗和互聯網整合營銷的理念，并將策略和執行緊密結合，為客戶提供全網互聯網整合方案。

再見，模型

刪掉你的 models 目錄了嗎?還沒刪就趕緊刪了!我們將要在 app 目錄下創建一個新的目錄，目錄名就以我們這個應用的名字來命名，比如  QuickBill。我們將繼續使用在前面章節中編寫的那些接口和類。

>注意使用場景：記住，如果你在構建一個很小的 Laravel 應用，那在models 目錄下寫幾個 Eloquent  模型其實挺合適的。但在本章節，我們主要關注如何開發適用于分層架構的大型復雜項目。

所以，我們現在有了個 app/QuickBill 目錄，它和應用目錄下的其他目錄如 Http 還有 Console 都是平級的。在 QuickBill  目錄下我們還可以創建幾個其他目錄，例如 Repositories 和 Billing 目錄。目錄都創建好以后，別忘了在 composer.json 文件里通過  PSR-4 自動載入機制將它們注冊到 QuickBill 命名空間下：

"autoload": {  "classmap": [  "database/seeds",  "database/factories"  ],  "psr-4": {  "App\\": "app/",  "QuickBill\\": "app/QuickBill"  } },

現在，我們把所有 Eloquent 模型類都放到 QuickBill 目錄下面。這樣我們就能很方便的以  QuickBill\User、QuickBill\Payment 這種方式來使用它們。Repositories 目錄下包含 PaymentRepository  和UserRepository 這種倉庫類，倉庫類里面包含了所有對數據的訪問功能，比如 getRecentPayments 和  getRichestUser。Billing 目錄包含了調用第三方支付服務(如 Stripe 和  Balanced)的類和接口。整個目錄結構現在應該類似這樣：

// app  // QuickBill  // Repositories  -> UserRepository.php  -> PaymentRepository.php  // Billing  -> BillerInterface.php  -> StripeBiller.php  // Notifications  -> BillingNotifierInterface.php  -> SmsBillingNotifier.php  User.php  Payment.php

數據驗證放在哪?在哪兒進行數據驗證常常困擾著開發人員。可以考慮將數據驗證方法寫進你的「實體」類里面(例如 User.php 和  Payment.php)。方法名可以設置為 validForCreation 或 hasValidDomain。或者你也可以專門創建一個驗證器類  UserValidator，放到 Validation 命名空間下，然后將這個驗證器類注入到你的 Repository  類里面。兩種方式你都可以試試，看哪個你更喜歡!當然在 Laravel 5.* 中，你不需要自己創建驗證器類了，通過 Laravel  自帶的驗證器類就可以滿足你的所有需求。

擺脫了 models  目錄的束縛后，你通常就能克服實現好的架構設計的心理障礙，也就能夠構建一個更合適應用的目錄結構。當然，你構建的每一個應用程序都會有一定的相似之處，因為不管多復雜的應用程序都需要一個數據訪問層(Repository)，以及一些外部服務層等等。

別害怕目錄：不要懼怕創建更多目錄來組織管理應用。將整個應用切割成多個細分的功能組件總是必要的，每一個功能組件都專注于某一項職責。跳出「模型」的框框來思考總是有幫助的。例如，我們之前就討論過，你可以創建一個  Repositories 目錄來存放所有的數據訪問類。

核心思想就是分層

你可能已經注意到，優化應用目錄結構的關鍵就是對不同組件的責任進行劃分，或者說為不同的職責創建不同的層。控制器只負責接收和響應 HTTP  請求，然后調用合適的業務邏輯層的類。你的業務邏輯/領域邏輯層才是應用最核心的部分，其中包含了讀取數據，驗證數據，執行支付，發送電子郵件，還有程序里所有其他功能的代碼。事實上，你的領域邏輯層不需要知道任何關于「Web」的事情!Web  層僅僅是一種訪問應用程序的傳輸機制，關于 Web 和 HTTP  請求的一切不應該超出路由和控制器層的范圍。做出好的架構設計的確很有挑戰性，但好的架構設計也會帶來可維護的、更加清晰的代碼。

舉個例子，與其在業務邏輯類里面直接獲取 Web 請求，不如把 Web  請求通過控制器傳遞給業務邏輯類。這個簡單的改動會將你的業務邏輯類和「Web」層解耦，并且不必擔心怎么去模擬 Web 請求，就可以輕松測試業務邏輯類：

class BillingController extends BaseController {    public function __construct(BillerInterface $biller)  {  $this->biller = $biller;  }    public function postCharge(Request $request)  {  $this->biller->chargeAccount(Auth::user(), $request->input('amount'));  return view('charge.success');  }   }

現在 chargeAccount 方法更容易測試了，由于我們不再需要在 BillerInterface 實現類中使用 User 和 Request  類，只需將用戶和金額傳遞到該方法即可。

編寫可維護性應用程序的關鍵之一，就是職責分離。要時常檢查一個類是否管得太寬，知道一些它不該知道的。你要常常問自己「這個類是否需要關心X?」如果答案是否定的，那么就要把這塊邏輯提取出來放到另一個類里面，然后用依賴注入的方式將其注入進來。

如何判斷一個類是否管得太寬?一個有用的方法就是檢查你為什么要改這塊代碼。舉個例子，當我們想調整通知邏輯的時候，是否需要修改 Biller  的實現代碼?當然不需要，Biller  實現只關注支付，它與通知邏輯應當僅通過契約來進行交互。在處理代碼時使用這種思路，可以幫助你快速找出應用中需要改進的地方。

東西都放哪兒?

當通過 Laravel  開發應用時，你可能會困惑于應該把各種「東西」放在哪里。例如，輔助函數要放在哪里?事件監聽器要放在哪里?視圖組件要放在哪里?答案可能出乎你的意料 ——  「隨便，放哪兒都行!」Laravel  并沒有很多關于這方面的文件系統上的約定。不過，這個答案的確不能讓人滿意，所以下面我們就這個問題展開討論，一起探討這些「東西」究竟可以放在哪里。

輔助函數

我們可以在 app 目錄下創建一個 helpers.php  文件，然后將自定義的輔助函數都放到這個文件中。當然，由于這個文件里面包含的不是類，不適合通過命名空間引用其中的函數，需要在 composer.json  中全局注冊它：

"autoload": {  ...  "files": [  "app/helpers.php"  ] },

然后運行 composer dump-auto 重新注冊自動加載映射關系。然后就可以在應用中使用 app/helpers.php  中定義的輔助函數了。

事件監聽器

事件監聽器當然不該放到 routes.php 文件里面，所以我們要找另外的地方來存放。事實上，在 Laravel 5.* 中，當我們通過 php  artisan make:listener 命令創建時間監聽器時，系統會自動在 app 目錄下創建 Listeners  子目錄，并將生成的監聽器類放到該目錄下。所以我們對于自定義的事件監聽器類，放到該目錄下即可。

錯誤處理器

在 Laravel 5.* 版本中，默認情況下所有的異常都是通過 App\Exceptions\Handler  來處理的，你也可以通過自定義的異常類來處理，自定義異常類可以放到 app/Exceptions 目錄下。

其他

通常，只要遵循 PSR-4  規范就可以在應用目錄結構中保持類的整齊。結合你目前為止學習到的知識，對于什么代碼要放在什么地方這個問題，應當可以給出一個有理有據的答案了。但永遠不要拒絕試驗。Laravel  的美妙之處就是你可以做出最適合你自己應用的約定。去探索和發現最適合你自己應用的結構吧，別忘了和他人分享你的見解!

例如，你可能受到我們之前例子的啟發，在 QuickBill 中創建一個 Providers 目錄來存放所有你自定義的服務提供者，目錄結構類似這樣：

// app  // QuickBill  // Billing  // Extensions  //Pagination  -> Environment.php  // Providers  -> EventPusherServiceProvider.php  // Repositories  User.php  Payment.php

注意上面的例子，我們有 Providers 和 Extensions 兩個命名空間。所有你自定義的服務提供者都可以放到 Providers 命名空間下，而  Extensions 命名空間可以用來存放你對框架核心進行擴展的類。

感謝各位的閱讀，以上就是“web開發中大型項目該怎么分層架構”的內容了，經過本文的學習后，相信大家對web開發中大型項目該怎么分層架構這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是創新互聯，小編將為大家推送更多相關知識點的文章，歡迎關注！

當前名稱：web開發中大型項目該怎么分層架構
網站網址：http://www.yijiale78.com/article30/gjhgpo.html

成都網站建設公司_創新互聯，為您提供網站內鏈、微信公眾號、網站設計、品牌網站設計、企業建站、響應式網站

廣告

聲明：本網站發布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網站立場，如需處理請聯系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經允許不得轉載，或轉載時需注明來源： 創新互聯