लारवेल की नई संदर्भ लाइब्रेरी के साथ भ्रमित न हों, इस पैकेज का उपयोग बहु-संदर्भ बहु-किरायेदार अनुप्रयोगों के निर्माण के लिए किया जा सकता है। अधिकांश बहु-किरायेदार पुस्तकालयों में अनिवार्य रूप से एक ही 'किरायेदार' संदर्भ होता है, इसलिए यदि आपको एकाधिक संदर्भों की आवश्यकता है, तो चीजें थोड़ी गड़बड़ हो सकती हैं। यह नया पैकेज उस समस्या का समाधान करता है।

क्या हम एक उदाहरण देखेंगे?

उदाहरण परियोजना

हमारे उदाहरण एप्लिकेशन के लिए हमारे पास एक वैश्विक उपयोगकर्ता-आधार होगा जो टीमों में व्यवस्थित है और प्रत्येक टीम के पास कई परियोजनाएं होंगी। सेवा अनुप्रयोगों के रूप में कई सॉफ़्टवेयर में यह एक काफी सामान्य संरचना है।

बहु-किरायेदार अनुप्रयोगों के लिए प्रत्येक उपयोगकर्ता-आधार का किरायेदार संदर्भ में मौजूद होना असामान्य नहीं है, लेकिन हमारे उदाहरण एप्लिकेशन के लिए, हम चाहते हैं कि उपयोगकर्ता कई टीमों में शामिल होने में सक्षम हों, इसलिए यह वैश्विक उपयोगकर्ता-आधार है।
वैश्विक उपयोगकर्ता-आधार बनाम किरायेदार उपयोगकर्ता-आधार आरेख

सास के रूप में, यह संभावना है कि टीम बिल योग्य इकाई (यानी सीट) होगी और टीम के कुछ सदस्यों को टीम का प्रबंधन करने की अनुमति दी जाएगी। हालाँकि, मैं इस उदाहरण में इन कार्यान्वयन विवरणों में नहीं जाऊंगा, लेकिन उम्मीद है कि यह कुछ अतिरिक्त संदर्भ प्रदान करेगा।

इंस्टालेशन

इस पोस्ट को संक्षिप्त रखने के लिए मैं यह नहीं बताऊंगा कि अपना लारवेल प्रोजेक्ट कैसे शुरू करें। इसके लिए पहले से ही कई बेहतर संसाधन उपलब्ध हैं, कम से कम आधिकारिक दस्तावेज़ीकरण तो नहीं। आइए मान लें कि आपके पास उपयोगकर्ता, टीम और प्रोजेक्ट मॉडल के साथ पहले से ही एक लारवेल प्रोजेक्ट है, और आप हमारे संदर्भ पैकेज को लागू करना शुरू करने के लिए तैयार हैं।

इंस्टॉलेशन एक साधारण संगीतकार की अनुशंसा है:

composer install honeystone/context

इस लाइब्रेरी में एक सुविधा फ़ंक्शन, context() है, जो Laravel 11 के अनुसार Laravel के स्वयं के संदर्भ फ़ंक्शन के साथ टकराता है। यह वास्तव में कोई समस्या नहीं है. आप या तो हमारा फ़ंक्शन आयात कर सकते हैं:

use function Honestone\Context\context;

या केवल लारवेल के निर्भरता इंजेक्शन कंटेनर का उपयोग करें। इस पूरे पोस्ट में मैं मान लूंगा कि आपने फ़ंक्शन आयात कर लिया है और तदनुसार इसका उपयोग करें।

मॉडल

आइए अपने टीम मॉडल को कॉन्फ़िगर करके शुरुआत करें:

belongsToMany(User::class);
    }

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

एक टीम का एक नाम, सदस्य और प्रोजेक्ट होते हैं। हमारे एप्लिकेशन के भीतर, केवल एक टीम के सदस्य ही टीम या उसके प्रोजेक्ट तक पहुंच पाएंगे।

ठीक है, तो आइए हमारे प्रोजेक्ट पर नजर डालें:

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);
    });
});

नेमस्पेस टकराव की संभावना को देखते हुए, यह एक बहुत ही अनम्य दृष्टिकोण है, लेकिन यह उदाहरण को संक्षिप्त रखता है। वास्तविक दुनिया के एप्लिकेशन में आप इसे थोड़ा अलग तरीके से संभालना चाहेंगे, शायद elsesaas.dev/teams/my-team/projects/my-project या my-team.anothersas.dev/projects/my-project।

हमें पहले अपने AppContextMiddleware को देखना चाहिए। यह मिडलवेयर टीम संदर्भ को प्रारंभ करता है और, यदि सेट किया गया है, तो प्रोजेक्ट संदर्भ:

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));
    }
}

शुरू करने के लिए हम रूट से टीम आईडी लेते हैं और फिर रूट पैरामीटर भूल जाते हैं। संदर्भ में आने के बाद हमें पैरामीटर को हमारे नियंत्रकों तक पहुंचने की आवश्यकता नहीं है। यदि कोई प्रोजेक्ट आईडी सेट है, तो हम उसे भी खींच लेते हैं। फिर हम अपनी टीम आईडी और अपनी प्रोजेक्ट आईडी (या शून्य) पास करते हुए अपने AppResolver का उपयोग करके संदर्भ आरंभ करते हैं:

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']);
    }
}

यहाँ कुछ और चल रहा है।

परिभाषित() विधि हल किए जा रहे संदर्भ को परिभाषित करने के लिए जिम्मेदार है। टीम आवश्यक है और एक टीम मॉडल होनी चाहिए, और प्रोजेक्ट स्वीकृत है (अर्थात वैकल्पिक) और एक प्रोजेक्ट मॉडल (या शून्य) होना चाहिए।

resolveTeam() को आरंभीकरण पर आंतरिक रूप से कॉल किया जाएगा। यह टीम या शून्य लौटाता है। शून्य प्रतिक्रिया की स्थिति में, ContextInitializer द्वारा IncludeNotResolveRequiredContextException को फेंक दिया जाएगा।

resolveProject() को आरंभीकरण पर आंतरिक रूप से भी बुलाया जाएगा। यह प्रोजेक्ट या शून्य लौटाता है। इस मामले में शून्य प्रतिक्रिया के परिणामस्वरूप अपवाद नहीं होगा क्योंकि परियोजना परिभाषा के अनुसार आवश्यक नहीं है।

टीम और प्रोजेक्ट को हल करने के बाद, ContextInitializer वैकल्पिक checkTeam() और checkProject() तरीकों को कॉल करेगा। ये विधियां अखंडता जांच करती हैं। checkTeam() के लिए हम सुनिश्चित करते हैं कि प्रमाणित उपयोगकर्ता टीम का सदस्य है, और checkProject() के लिए हम जाँचते हैं कि प्रोजेक्ट टीम का है।

आखिरकार, प्रत्येक रिज़ॉल्वर को एक डिसेरिएलाइज़ेशन() विधि की आवश्यकता होती है। इस पद्धति का उपयोग क्रमबद्ध संदर्भ को पुनर्स्थापित करने के लिए किया जाता है। विशेष रूप से ऐसा तब होता है जब संदर्भ का उपयोग कतारबद्ध कार्य में किया जाता है।

अब जब हमारा एप्लिकेशन संदर्भ सेट हो गया है, तो हमें इसका उपयोग करना चाहिए।

संदर्भ तक पहुँचना

हमेशा की तरह, अगर थोड़ा सा आविष्कार हुआ तो हम इसे सरल रखेंगे। टीम को देखते समय हम परियोजनाओं की एक सूची देखना चाहते हैं। हम इस आवश्यकता को इस तरह से संभालने के लिए अपना टीमकंट्रोलर बना सकते हैं:

projects;

        return view('team', compact('projects'));
    }
}

काफ़ी आसान। वर्तमान टीम संदर्भ से संबंधित परियोजनाएं हमारे विचार में पारित कर दी गई हैं। कल्पना कीजिए कि अब हमें अधिक विशिष्ट दृश्य के लिए परियोजनाओं को क्वेरी करने की आवश्यकता है। हम यह कर सकते हैं:

id)
            ->where('name', 'like', "%$query%")
            ->get();

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

यह अब थोड़ा अजीब हो गया है, और गलती से टीम द्वारा क्वेरी को 'स्कोप' करना भूल जाना बहुत आसान है। हम अपने प्रोजेक्ट मॉडल पर BelongsToContext विशेषता का उपयोग करके इसे हल कर सकते हैं:

belongsTo(Team::class);
    }
}

सभी प्रोजेक्ट क्वेरीज़ को अब टीम संदर्भ द्वारा स्कूप किया जाएगा और वर्तमान टीम मॉडल स्वचालित रूप से नए प्रोजेक्ट मॉडल में इंजेक्ट किया जाएगा।

आइए उस नियंत्रक को सरल बनाएं:

get();

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

कि सभी लोग

यहां से, आप बस अपना एप्लिकेशन बना रहे हैं। संदर्भ आसानी से हाथ में है, आपके प्रश्नों का दायरा है और कतारबद्ध नौकरियों को स्वचालित रूप से उसी संदर्भ तक पहुंच प्राप्त होगी जहां से उन्हें भेजा गया था।

हालांकि संदर्भ संबंधी सभी समस्याएं हल नहीं होती हैं। आप शायद अपने सत्यापन नियमों को थोड़ा संदर्भ देने के लिए कुछ सत्यापन मैक्रोज़ बनाना चाहेंगे, और यह न भूलें कि मैन्युअल क्वेरी में संदर्भ स्वचालित रूप से लागू नहीं होगा।

यदि आप इस पैकेज को अपने अगले प्रोजेक्ट में उपयोग करने की योजना बना रहे हैं, तो हमें आपसे सुनना अच्छा लगेगा। प्रतिक्रिया और योगदान का हमेशा स्वागत है।

आप अतिरिक्त दस्तावेज़ीकरण के लिए GitHub रिपॉजिटरी को चेकआउट कर सकते हैं। यदि आपको हमारा पैकेज उपयोगी लगता है, तो कृपया एक सितारा लगाएं।

अगली बार तक..

यह लेख मूल रूप से हनीस्टोन ब्लॉग पर पोस्ट किया गया था। यदि आपको हमारे लेख पसंद आते हैं, तो वहां हमारी और सामग्री की जांच करने पर विचार करें।