不要與 Laravel 的新上下文庫混淆，該套件可用於建立多上下文多租戶應用程式。大多數多租戶庫本質上都有一個「租戶」上下文，因此如果您需要多個上下文，事情可能會變得有點複雜。這個新包解決了這個問題。
讓我們來看一個例子好嗎？
對於我們的範例應用程序，我們將擁有一個組織成團隊的全球用戶群，每個團隊將有多個專案。這是許多軟體即服務應用程式中相當常見的結構。
對於多租戶應用程式來說，每個用戶群都存在於一個租戶上下文中並不罕見，但對於我們的範例應用程序，我們希望用戶能夠加入多個團隊，所以它是全局用戶群。
全球用戶群與租用戶用戶群圖
作為 SaaS，團隊很可能是計費實體（即席位），並且某些團隊成員將被授予管理團隊的權限。不過，我不會在此範例中深入探討這些實作細節，但希望它提供一些額外的上下文。
為了保持這篇文章的簡潔，我不會解釋如何啟動你的 Laravel 專案。已經有許多更好的資源可用，尤其是官方文件。我們假設您已經有一個 Laravel 項目，其中包含使用者、團隊和專案模型，並且您已準備好開始實作我們的上下文套件。
安裝很簡單 作曲家推薦：
雷雷
這個函式庫有一個方便的函數 context()，從 Laravel 11 開始，它與 Laravel 自己的 context 函數發生衝突。這其實不是一個問題。您可以匯入我們的函數：
雷雷
或直接使用 Laravel 的依賴注入容器。在這篇文章中，我將假設您已匯入該函數並相應地使用它。
讓我們從配置我們的團隊模型開始：
雷雷
團隊有名稱、成員和專案。在我們的應用程式中，只有團隊成員才能存取該團隊或其專案。
好吧，讓我們看看我們的專案：
雷雷
一個專案有一個名字並且屬於一個團隊。
當有人訪問我們的應用程式時，我們需要確定他們在哪個團隊和專案中工作。為了簡單起見，我們用路由參數來處理這個問題。我們還假設只有經過身份驗證的用戶才能存取該應用程式。
既不是團隊也不是專案脈絡： app.mysaas.dev
僅隊上下文： app.mysaas.dev/my-team
團隊和專案上下文： app.mysaas.dev/my-team/my-project
我們的路線將如下圖所示：
雷雷
考慮到命名空間衝突的可能性，這是一種非常不靈活的方法，但它使範例保持簡潔。在現實世界的應用程式中，您需要稍微不同地處理這個問題，也許是 anothersaas.dev/teams/my-team/projects/my-project 或 my-team.anothersas.dev/projects/my-project。
我們應該先看看我們的AppContextMiddleware。此中間件初始化團隊上下文以及專案上下文（如果設定）：
雷雷
首先，我們從路線中取得團隊 ID，然後忘記路線參數。一旦參數進入上下文，我們就不需要到達控制器。如果設定了項目 ID，我們也會提取它。然後，我們使用 AppResolver 傳遞團隊 id 和專案 id（或 null）來初始化上下文：
雷雷
這裡還有更多事情要做。
define() 方法負責定義正在解析的上下文。團隊是必要的且必須是 Team 模型，且專案被接受（即可選）且必須是 Project 模型（或 null）。
resolveTeam() 將在初始化時在內部呼叫。它傳回 Team 或 null。如果出現空響應，ContextInitializer 將拋出 CouldNotResolveRequiredContextException。
resolveProject() 也會在初始化時在內部呼叫。它傳回項目或 null。在這種情況下，空響應不會導致異常，因為定義不需要該項目。
解析團隊和專案後，ContextInitializer 會呼叫可選的 checkTeam() 和 checkProject() 方法。這些方法執行完整性檢查。對於 checkTeam()，我們確保經過驗證的使用者是團隊的成員，對於 checkProject()，我們檢查專案是否屬於團隊。
Finally, every resolver needs a deserialization() method. This method is used to reinstate a serialised context. Most notably this happens when the context is used in a queued job.
Now that our application context is set, we should use it.
As usual, we’ll keep it simple, if a little contrived. When viewing the team we want to see a list of projects. We could build our TeamController to handle this requirements like this:
<?php
declare(strict_types=1);
namespace App\Http\Controllers;
use Illuminate\View\View;
use function compact;
use function Honestone\Context\context;
use function view;
class TeamController
{
public function __invoke(Request $request): View
{
$projects = context('team')->projects;
return view('team', compact('projects'));
}
}Easy enough. The projects belonging to the current team context are passed to our view. Imagine we now need to query projects for a more specialised view. We could do this:
<?php
declare(strict_types=1);
namespace App\Http\Controllers;
use Illuminate\View\View;
use function compact;
use function Honestone\Context\context;
use function view;
class ProjectQueryController
{
public function __invoke(Request $request, string $query): View
{
$projects = Project::where('team_id', context('team')->id)
->where('name', 'like', "%$query%")
->get();
return view('queried-projects', compact('projects'));
}
}It’s getting a little fiddly now, and it’s far too easy to accidentally forget to ‘scope’ the query by team. We can solve this using the BelongsToContext trait on our Project model:
<?php
declare(strict_types=1);
namespace App\Models;
use Honeystone\Context\Models\Concerns\BelongsToContext;
use Illuminate\Database\Eloquent\Model;
use Illuminate\Database\Eloquent\Relations\BelongsTo;
class Project extends Model
{
use BelongsToContext;
protected static array $context = ['team'];
protected $fillable = ['name'];
public function team(): BelongsTo
{
return $this->belongsTo(Team::class);
}
}All project queries will now be scooped by the team context and the current Team model will be automatically injected into new Project models.
Let’s simplify that controller:
<?php
declare(strict_types=1);
namespace App\Http\Controllers;
use Illuminate\View\View;
use function compact;
use function view;
class ProjectQueryController
{
public function __invoke(Request $request, string $query): View
{
$projects = Project::where('name', 'like', "%$query%")->get();
return view('queried-projects', compact('projects'));
}
}From here onwards, you’re just building your application. The context is easily at hand, your queries are scoped and queued jobs will automagically have access to the same context from which they were dispatched.
Not all context related problems are solved though. You’ll probably want to create some validation macros to give your validation rules a little context, and don’t forget manual queries will not have the context automatically applied.
If you’re planning to use this package in your next project, we’d love to hear from you. Feedback and contribution is always welcome.
You can checkout the GitHub repository for additional documentation. If you find our package useful, please drop a star.
Until next time..
This article was originally posted to the Honeystone Blog. If you like our articles, consider checking our more of our content over there.
以上是使用 honeystone/context 建立多租戶應用程式的詳細內容。更多資訊請關注PHP中文網其他相關文章！
