使用 honeystone/context 建立多租戶應用程式

不要與 Laravel 的新上下文庫混淆，該套件可用於建立多上下文多租戶應用程式。大多數多租戶庫本質上都有一個「租戶」上下文，因此如果您需要多個上下文，事情可能會變得有點麻煩。這個新包解決了這個問題。

讓我們來看一個範例吧？

範例專案

對於我們的範例應用程序，我們將擁有一個全球用戶群，即組織成團隊，每個團隊將有多個專案。這是許多軟體即服務應用程式中相當常見的結構。

對於多租戶應用程式來說，每個用戶群都存在於租戶上下文中並不罕見，但對於我們的示例應用程序，我們希望用戶能夠加入多個團隊，所以是全球用戶群。
全球用戶群與租戶用戶群圖

作為SaaS，很可能該團隊將是計費實體（即席位），並且某些團隊成員將被授予管理團隊的權限。不過，我不會在這個範例中深入探討這些實作細節，但希望它能提供一些額外的上下文。

安裝

為了保持這篇文章的簡潔，我不會解釋如何啟動你的 Laravel專案。已經有許多更好的資源可用，尤其是官方文件。我們假設您已經有一個 Laravel 項目，包含使用者、團隊和專案模型，並且您已準備好開始實作我們的上下文套件。

安裝是一個簡單的作曲家推薦：

composer install honeystone/context

這個函式庫有一個方便的函數context()，從Laravel 11 開始，它與Laravel 自己的context 函數發生衝突。這其實不是一個問題。您可以匯入我們的函數：

use function Honestone\Context\context;

或只使用 Laravel 的依賴注入容器。在這篇文章中，我將假設您已匯入該函數並相應地使用它。

模型

讓我們從配置我們的團隊模型開始：

<?php declare(strict_types=1);

namespace App\Models;

use Illuminate\Database\Eloquent\Model;
use Illuminate\Database\Eloquent\Relations\BelongsToMany;
use Illuminate\Database\Eloquent\Relations\HasMany;

class Team extends Model
{
    protected $fillable = [&#39;name&#39;];

    public function members(): BelongsToMany
    {
        return $this->belongsToMany(User::class);
    }

    public function projects(): HasMany
    {
        return $this->hasMany(Project::class);
    }
}

團隊有名稱、成員和專案。在我們的應用程式中，只有團隊成員才能存取該團隊或其專案。

好的，讓我們看看我們的專案：

<?php declare(strict_types=1);

namespace App\Models;

use Illuminate\Database\Eloquent\Model;
use Illuminate\Database\Eloquent\Relations\BelongsTo;

class Project extends Model
{
    protected $fillable = [&#39;name&#39;];

    public function team(): BelongsTo
    {
        return $this->belongsTo(Team::class);
    }
}

一個專案有一個名稱並屬於一個團隊。

確定上下文

當有人訪問我們的應用程式時，我們需要確定他們在哪個團隊和專案中工作。為了簡單起見，我們用路由參數來處理這個問題。我們還假設只有經過身份驗證的用戶才能存取該應用程式。

團隊和專案上下文都不是： app.mysaas.dev
僅團隊上下文： app.mysaas.dev/my-team
團隊與專案情境： app.mysaas.dev/my-team/my-project

我們的路線將如下所示：

Route::middleware('auth')->group(function () {

    Route::get('/', DashboardController::class);

    Route::middleware(AppContextMiddleware::Class)->group(function () {

        Route::get('/{team}', TeamController::class);
        Route::get('/{team}/{project}', ProjectController::class);
    });
});

考慮到命名空間衝突的可能性，這是一種非常不靈活的方法，但它使範例保持簡潔。在現實世界的應用程式中，您需要稍微不同地處理這個問題，也許是 anothersaas.dev/teams/my-team/projects/my-project 或 my-team.anothersas.dev/projects/my-project。

我們應該先看看我們的AppContextMiddleware。此中間件初始化團隊上下文，以及專案上下文（如果已設定）：

<?php declare(strict_types=1);

namespace App\Http\Middleware;

use function Honestone\Context\context;

class TeamContextMiddleware
{
    public function handle(Request $request, Closure $next): mixed
    {
        //pull the team parameter from the route
        $teamId = $request->route('team');
        $request->route()->forgetParameter('team');

        $projectId = null;

        //if there's a project, pull that too
        if ($request->route()->hasParamater('project')) {

            $projectId = $request->route('project');
            $request->route()->forgetParameter('project');
        }

        //initialise the context
        context()->initialize(new AppResolver($teamId, $projectId));
    }
}

首先，我們從路由中取得團隊 ID，然後忘記路由參數。一旦參數進入上下文，我們就不需要到達控制器。如果設定了項目 ID，我們也會提取它。然後，我們使用 AppResolver 傳遞團隊 id 和專案 id（或 null）來初始化上下文：

<?php declare(strict_types=1);

namespace App\Context\Resolvers;

use App\Models\Team;
use Honeystone\Context\ContextResolver;
use Honeystone\Context\Contracts\DefinesContext;

use function Honestone\Context\context;

class AppResolver extends ContextResolver
{
    public function __construct(
        private readonly int $teamId,
        private readonly ?int $projectId = null,
    ) {}

    public function define(DefinesContext $definition): void 
    {
        $definition
            ->require('team', Team::class)
            ->accept('project', Project::class);
    }

    public function resolveTeam(): ?Team
    {
        return Team::with('members')->find($this->teamId);
    }

    public function resolveProject(): ?Project
    {
        return $this->projectId ?: Project::with('team')->find($this->projectId);
    }

    public function checkTeam(DefinesContext $definition, Team $team): bool
    {
        return $team->members->find(context()->auth()->getUser()) !== null;
    }

    public function checkProject(DefinesContext $definition, ?Project $project): bool
    {
        return $project === null || $project->team->id === $this->teamId;
    }

    public function deserialize(array $data): self
    {
        return new static($data['team'], $data['project']);
    }
}

這裡還有更多內容。

define( ) 方法負責定義正在解析的上下文。團隊是必要的且必須是團隊模型，專案被接受（即可選）且必須是專案模型（或為空）。

resolveTeam() 將在初始化時在內部呼叫。它傳回 Team 或 null。如果出現空響應，ContextInitializer 將拋出 CouldNotResolveRequiredContextException。

resolveProject() 也會在初始化時在內部呼叫。它傳回項目或 null。在這種情況下，空響應不會導致異常，因為定義不需要該項目。

解析團隊和專案後，ContextInitializer 會呼叫可選的 checkTeam() 和 checkProject() 方法。這些方法執行完整性檢查。對於 checkTeam()，我們確保經過驗證的使用者是團隊的成員，對於 checkProject()，我們檢查專案是否屬於團隊。

最後，每個解析器都需要一個 deserialization() 方法。此方法用於恢復序列化上下文。最值得注意的是，當在排隊作業中使用上下文時，會發生這種情況。

Now that our application context is set, we should use it.

Accessing the context

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(&#39;team&#39;)->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(&#39;team_id&#39;, context(&#39;team&#39;)->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 = [&#39;team&#39;];

    protected $fillable = [&#39;name&#39;];

    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(&#39;name&#39;, &#39;like&#39;, "%$query%")->get();

        return view('queried-projects', compact('projects'));
    }
}

That’s all folks

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中文網其他相關文章！