Laravel ची $casts प्रॉपर्टी ही अशा काही शांत सोयींपैकी एक आहे जी फारसा लक्ष वेधून न घेता तुम्ही डेटा कसा हाताळता याला आकार देते. ॲरेमध्ये boolean किंवा datetime सारखा इन-बिल्ट (built-in) प्रकार टाका, आणि Eloquent आपोआप डेटाबेसच्या रॉ (raw) स्ट्रिंग्सना तुमच्या कंट्रोलर्स किंवा व्ह्यूजमध्ये पोहोचण्यापूर्वी अधिक सोप्या स्वरूपात रूपांतरित करते. यामुळे तुमचा कोड नीटनेटका राहतो. पण ज्या क्षणी तुम्ही त्या ॲरेमध्ये थेट तुमचे स्वतःचे हेल्पर फंक्शन कॉल करण्याचा प्रयत्न करता, तेव्हा फ्रेमवर्क अडथळा निर्माण करते. 'username' => 'encrypt_data()' असे लिहिणे काम करणार नाही. Laravel ला एकतर नेटिव्ह कास्ट कीवर्ड किंवा CastsAttributes इंटरफेस लागू करणारी क्लास (class) अपेक्षित असते. ही आवश्यकता यासाठी आहे कारण कास्टिंग लेयर Eloquent च्या हायड्रेशन (hydration) आणि सिरीयलायझेशन (serialization) सायकलमध्ये खोलवर कार्यरत असते; त्याला रनटाइमला अस्तित्वात नसूनही शक्य असलेल्या कोणत्याही अनिश्चित फंक्शन स्ट्रिंगपेक्षा, स्पष्ट करारासह (contract) एक अंदाजित ऑब्जेक्ट हवा असतो.

$casts ॲरेमध्ये हेल्पर फंक्शन्स का अयशस्वी होतात?

जेव्हा Eloquent मॉडेल लोड करते, तेव्हा प्रत्येक कॉलम कसा रूपांतरित करायचा हे ठरवण्यासाठी ते $casts ॲरे स्कॅन करते. फ्रेमवर्क विशिष्ट प्रिमिटिव्हज (primitives)—string, integer, array, encrypted इत्यादी ओळखते—आणि CastsAttributes लागू करणारी पूर्णपणे क्वालिफाईड क्लास नावे (fully-qualified class names) देखील ओळखते. ते स्ट्रिंगला कोड म्हणून इव्हॅल्युएट (evaluate) करत नाही. त्यामुळे 'encrypt_data()' ला एक अज्ञात कास्ट प्रकार मानले जाते, ज्यामुळे एरर (error) येतो. जरी Laravel ने त्याचे पार्सिंग केले असते, तरीही मॉडेल इन्स्टन्स, ॲट्रिब्यूट की, सध्याची व्हॅल्यू आणि सभोवतालचे ॲट्रिब्युट्स तुमच्या फंक्शनमध्ये योग्य क्रमाने पास करण्याचा कोणताही विश्वसनीय मार्ग नसेल. तुमच्या कस्टम लॉजिक आणि Eloquent च्या अंतर्गत प्रक्रियेमधील (internals) तो संवाद प्रमाणित करण्यासाठीच हे इंटरफेस अस्तित्वात आहे.

हा फरक भरून काढण्याचे तुमच्याकडे दोन ठोस मार्ग आहेत. एक मार्ग दीर्घकालीन पुनरुपयोगासाठी (reuse) चांगला आहे, तर दुसरा मार्ग तेव्हा उपयुक्त ठरतो जेव्हा तुम्हाला फक्त एका मॉडेलमध्ये त्वरित बदल (quick patch) करायचा असतो.

पद्धत १: कस्टम कास्ट क्लास (Custom Cast Class) लिहा

जर तेच रूपांतरण अनेक फील्ड्सना लागू होत असेल किंवा अनेक मॉडेल्समध्ये पसरलेले असेल, तर समर्पित कास्ट क्लास वापरणे हा अधिक स्वच्छ पर्याय आहे. तो स्वतःच्या स्वतंत्र फाईलमध्ये असतो, त्याला स्वतंत्रपणे युनिट-टेस्ट (unit-test) करता येते आणि यामुळे तुमचे मॉडेल्स वारंवार लागणाऱ्या बोइलरप्लेट (boilerplate) कोडपासून मुक्त राहतात.

app/Casts/CustomEncrypt.php तयार करून सुरुवात करा. नेमस्पेस (namespace) तुमच्या ऑटोलोडिंग सेटअपशी जुळला पाहिजे, सामान्यतः App\Casts. क्लासने Illuminate\Contracts\Database\Eloquent\CastsAttributes लागू करणे आवश्यक आहे, ज्यामुळे तुम्हाला get आणि set हे दोन मेथड्स (methods) परिभाषित करावे लागतील.

<?php

namespace App\Casts;

use Illuminate\Contracts\Database\Eloquent\CastsAttributes;
use Illuminate\Database\Eloquent\Model;

class CustomEncrypt implements CastsAttributes
{
    public function get(Model $model, string $key, mixed $value, array $attributes): mixed
    {
        return decrypt_data($value);
    }

    public function set(Model $model, string $key, mixed $value, array $attributes): mixed
    {
        return encrypt_data($value);
    }
}

सिग्नेचर्स (signatures) महत्त्वाचे आहेत. Eloquent प्रत्येक मेथडमध्ये चार आर्ग्युमेंट्स (arguments) पास करते. $model हा भरला जाणारा किंवा सेव्ह केला जाणारा इन्स्टन्स आहे, ज्यामुळे जर तुमचे लॉजिक इतर फील्ड्सवर अवलंबून असेल, तर तुम्ही त्यांची तपासणी करू शकता. $key हा सध्या कास्ट केला जाणारा कॉलमचा नाव आहे. $value म्हणजे get करताना डेटाबेसमधून येणारी रॉ स्ट्रिंग किंवा null आहे, किंवा set करताना वापरकर्त्याने दिलेली व्हॅल्यू आहे. $attributes म्हणजे त्या रो (row) साठीच्या सर्व कॉलम्सचा रॉ ॲरे (raw array) आहे. तुम्हाला प्रत्येक वेळी चारही वापरण्याची गरज नाही, परंतु इंटरफेससाठी ते आवश्यक आहेत.

वरील get मेथडमध्ये, Eloquent डेटाबेसमधून रो फेच केल्यानंतर आणि व्हॅल्यू तुमच्या मॉडेलवर येण्यापूर्वी decrypt_data($value) चालते. set मेथडमध्ये, INSERT किंवा UPDATE करण्यापूर्वी encrypt_data($value) चालते, ज्यामुळे डेटाबेसमध्ये कधीही प्लेनटेक्स्ट (plaintext) जात नाही याची खात्री होते.

हे लागू करण्यासाठी, तुमच्या मॉडेलच्या $casts ॲरेमध्ये क्लासचा संदर्भ द्या:

protected $casts = [
    'username' => CustomEncrypt::class,
    'password' => CustomEncrypt::class,
];

तुम्ही क्लास कॉन्स्टंट (class constant) वापरत असल्यामुळे, ऑटोलोडर बाकीचे काम हाताळतो. जर तुमच्या ॲप्लिकेशनला नंतर एन्क्रिप्शन स्कीम बदलावी लागली, तर तुम्हाला फक्त एक फाईल एडिट करावी लागेल आणि प्रत्येक मॅप्ड फील्डचे वर्तन त्वरित बदलेल. जेव्हा तुम्ही अनेक टेबल्समध्ये संवेदनशील डेटा व्यवस्थापित करत असता, तेव्हा ही केंद्रीकृत पद्धत (centralization) अत्यंत प्रभावी ठरते.

पद्धत २: ॲक्सेसर (Accessor) आणि म्यूटेटर (Mutator) वापरा

कधीकधी तुम्हाला अशा रूपांतरणासाठी नवीन फाईल नको असते जे फक्त एकाच ठिकाणी महत्त्वाचे असते. Laravel ची Attribute क्लास तुम्हाला PHP 8+ क्लोजर (closure) सिंटॅक्स वापरून थेट मॉडेलवर get आणि set लॉजिक परिभाषित करण्याची परवानगी देते.

use Illuminate\Database\Eloquent\Casts\Attribute;

protected function username(): Attribute
{
    return Attribute::make(
        get: fn ($value) => decrypt_data($value),
        set: fn ($value) => encrypt_data($value),
    );
}

येथे मेथडचे नाव तुम्ही लक्ष्य करत असलेल्या कॉलम किंवा ॲट्रिब्यूटशी जुळले पाहिजे. जेव्हा Eloquent डेटाबेसमधून username वाचते, तेव्हा ते रॉ व्हॅल्यू get क्लोजरद्वारे पास करते. जेव्हा तुम्ही मॉडेलच्या username प्रॉपर्टीला नवीन व्हॅल्यू नियुक्त करता, तेव्हा Eloquent क्वेरी तयार करण्यापूर्वी set क्लोजर ती एन्क्रिप्ट करते.

हा दृष्टिकोन प्रोटोटाइप्स किंवा लेगसी मॉडेल्समध्ये उत्तम काम करतो, जिथे कास्ट क्लासेसची पूर्ण डिरेक्टरी तयार करणे अनावश्यक वाटते. याचा तोटा म्हणजे पुनरावृत्ती (repetition). जर तुम्ही नंतर ठरवले की email, phone, आणि backup_code ला देखील तेच ट्रीटमेंट हवे आहे, तर तुम्हाला ते क्लोजर्स अनेक मेथड्स किंवा मॉडेल्समध्ये कॉपी करावे लागतील. यामुळे कोडमध्ये अनावश्यक गर्दी (noise) वाढते. तसेच, यामुळे संपूर्ण मॉडेल बूट न करता युनिट टेस्टमध्ये लॉजिकचा पुनरुपयोग करणे कठीण होते.

या दोनपैकी एकाची निवड करणे

जेव्हा तुम्हाला पुनरुपयोग (reuse), टेस्टिंग आणि मॉडेल्स सुटसुटीत (slim) ठेवण्याबद्दल काळजी असेल, तेव्हा कस्टम कास्ट क्लासचा (custom cast class) वापर करा. हे इतर डेव्हलपर्सना सूचित करते की हे रूपांतरण तुमच्या ॲप्लिकेशनमधील एक महत्त्वाचा भाग आहे, केवळ एखादा तात्पुरता उपाय (hack) नाही.

जेव्हा लॉजिक खरोखर स्थानिक (localized), प्रायोगिक किंवा सध्याच्या स्प्रिंटच्या पलीकडे टिकण्याची शक्यता कमी असेल, तेव्हा ॲक्सेसरचा (accessor) वापर करा. यामुळे कोडबेसमध्ये अनेक लहान फाईल्स विखुरल्याशिवाय तुम्ही वेगाने काम करू शकता. फक्त, जेव्हा तोच पॅटर्न दुसऱ्या किंवा तिसऱ्यांदा दिसून येईल, तेव्हा त्याला कास्ट क्लासमध्ये रिफॅक्टर (refactor) करण्यासाठी तयार राहा.

लक्षात ठेवण्यासारखे व्यावहारिक तपशील

कस्टम कास्ट्स शक्तिशाली असतात, परंतु जर तुम्ही लक्ष दिले नाही तर ते असे वर्तन (behavior) दर्शवू शकतात जे तुम्हाला आश्चर्यचकित करू शकते. पहिले, लक्षात ठेवा की get ला डेटाबेसने जे काही परत केले आहे ते मिळते, ज्यामध्ये null चा देखील समावेश असतो. जर decrypt_data नल (null) इनपुट स्वीकारत नसेल, तर त्यापासून संरक्षण करण्यासाठी उपाय करा:

public function get(Model $model, string $key, mixed $value, array $attributes): mixed
{
    return is_null($value) ? null : decrypt_data($value);
}

दुसरे म्हणजे, कास्ट्स ॲरे (array) आणि JSON सिरीयलायझेशन (serialization) दरम्यान चालतात. जेव्हा तुम्ही मॉडेल API रिसोर्स म्हणून परत करता किंवा toArray() कॉल करता, तेव्हा कास्ट get लॉजिक अजूनही लागू होते. सहसा तुम्हाला हेच हवे असते, परंतु जर तुम्ही डिक्रिप्ट केलेली मूल्ये (decrypted values) प्रदर्शित करत असाल आणि त्यावर अतिरिक्त व्हिजिबिलिटी कंट्रोल्स (visibility controls) लावायचे असतील, तर हे लक्षात ठेवणे महत्त्वाचे आहे.

तिसरे आणि सर्वात महत्त्वाचे म्हणजे, कास्टिंग हे डेटा मिळवल्यानंतर (after retrieval) होते. तुम्ही रूपांतरित केलेल्या मूल्यावर (transformed value) क्वेरी करू शकत नाही. User::where('username', 'john_doe')->first() सारखी क्वेरी john_doe ही स्ट्रिंग थेट डेटाबेसकडे पाठवते. ती तुमच्या डिक्रिप्ट लॉजिकमधून कधीही जात नाही. जर कॉलम 'encrypted at rest' असेल, तर जोपर्यंत तुम्ही एन्क्रिप्टेड सायफरटेक्स्ट (ciphertext) विरुद्ध शोधत नाही, तोपर्यंत ती क्वेरी काहीही शोधू शकणार नाही. तुमच्या डेटाबेस ॲक्सेस पॅटर्नचे नियोजन त्यानुसार करा, कारण कास्ट्स हे नेटिव्ह डेटाबेस फंक्शन्स किंवा इंडेक्स्ड प्लेनटेक्स्ट कॉलम्सचा पर्याय नाहीत.

कस्टम कास्ट क्लासेस कॉन्फिगरेशनच्या लहान भागांसाठी देखील उत्तम ठिकाण आहेत. जर तुम्हाला कन्स्ट्रक्टर आर्ग्युमेंट्सची (constructor arguments) गरज असेल—कदाचित सायफर मोड किंवा फॉरमॅट स्ट्रिंग पास करणे—तर Laravel $casts ॲरेद्वारे 'field' => CustomEncrypt::class . ':arg' सारख्या एक्सप्रेशनचा वापर करून त्यांना सपोर्ट करते, जरी हे येथे वर्णन केलेल्या मूलभूत सेटअपपेक्षा एक पाऊल पुढे आहे.

मुख्य निष्कर्ष

$casts मध्ये थेट हेल्पर फंक्शन्स वापरण्यावर असलेली मर्यादा ही केवळ विनाकारण केलेली प्रक्रिया नाही. ती तुम्हाला स्पष्ट (explicit), टेस्ट करण्यायोग्य (testable) आणि पुनरुपयोगी (reusable) कोडकडे वळवते. कस्टम कास्ट क्लासेस विखुरलेल्या इनलाइन लॉजिकचे विश्वासार्ह घटकांमध्ये (components) रूपांतर करतात, जे तुम्ही कोणत्याही डुप्लिकेशनशिवाय मॉडेल्समध्ये शेअर करू शकता. जेव्हा वेगळी फाईल तयार करणे अनावश्यक औपचारिकता वाटते, तेव्हा ॲक्सेसर जलद आणि स्थानिक दुरुस्तीसाठी मार्ग मोकळा ठेवतात. दोन्हीमध्ये प्रभुत्व मिळवा, समस्येच्या व्याप्तीनुसार निवड करा आणि तुमचे ॲप्लिकेशन कितीही मोठे झाले तरी तुमचे Eloquent लेअर वाचनीय राहील.