Laravel में बाइंडरों का उपयोग करके कम डुप्लिकेट कोड लिखें

अच्छा समय, देवियों और सज्जनों।

बहुत पहले नहीं जब मैंने लारवेल में किसी एकल परियोजना की समीक्षा करते समय डुप्लिकेट और डुप्लिकेट कोड की घटना का सामना किया।

लब्बोलुआब यह है: सिस्टम में AJAX अनुरोधों के लिए आंतरिक एपीआई की कुछ संरचना है, अनिवार्य रूप से डेटाबेस (आदेश, उपयोगकर्ता, कोटा, आदि ...) से कुछ का संग्रह लौटाता है। इस संरचना का पूरा बिंदु परिणामों के साथ JSON को वापस करना है, और नहीं। कोड की समीक्षा में, मैंने एक ही कोड का उपयोग करके 5 या 6 कक्षाएं गिना, केवल अंतर रिसोर्सकॉलिनेशन, JsonResource और मॉडल के ही निर्भरता इंजेक्शन में था। यह दृष्टिकोण मेरे लिए मौलिक रूप से गलत लग रहा था, और मैंने अपना खुद का बनाने का फैसला किया, जैसा कि मेरा मानना ​​है, इस कोड में सही परिवर्तन, शक्तिशाली डि का उपयोग करके जो कि लारवेल फ्रेमवर्क हमें प्रदान करता है।

इसलिए, मैं बाद में किस बारे में बात करता हूं, मैं कैसे आया।

मेरे पास पहले से ही Magento 2 के लिए लगभग डेढ़ साल का अनुभव है, और जब मैंने पहली बार इस CMS का सामना किया, तो मुझे अपने डॉ के बारे में झटका लगा। उन लोगों के लिए जो नहीं जानते हैं: मैगेंटो 2 में, सिस्टम का एक छोटा हिस्सा तथाकथित "आभासी प्रकार" पर नहीं बनाया गया है। यही है, एक विशेष वर्ग का जिक्र करते हुए, हम हमेशा "वास्तविक" वर्ग की ओर मुड़ते नहीं हैं। हम आभासी प्रकार का उल्लेख करते हैं, जो एक निश्चित "वास्तविक" वर्ग (उदाहरण के लिए, व्यवस्थापक ग्रिड के लिए संग्रह, डीआई के माध्यम से एकत्र) के आधार पर "इकट्ठा" किया गया था। यह है, हम वास्तव में DI में समान कुछ लिखकर अपनी निर्भरता के साथ उपयोग के लिए किसी भी वर्ग का निर्माण कर सकते हैं:

<virtualType name="Vendor\Module\Model\ResourceModel\MyData\Grid\Collection" type="Magento\Framework\View\Element\UiComponent\DataProvider\SearchResult"> <arguments> <argument name="mainTable" xsi:type="string">vendor_table</argument> <argument name="resourceModel" xsi:type="string">Vendor\Module\Model\ResourceModel\MyData </argument> </arguments> </virtualType> 

अब, Vendor \ Module \ Model \ ResourceModel \ MyData \ Grid \ Collection वर्ग का अनुरोध करके, हमें Magento \ फ्रेमवर्क \ View \ Element \ UiComponent \ DataProvider \ Searchbult का एक उदाहरण मिलता है, लेकिन मुख्य विक्रेता के साथ "विक्रेता_ संगत" और ResourceModel पर निर्भर करता है। विक्रेता \ मॉड्यूल \ मॉडल \ रिसोर्समॉडल \ मायडाटा। "

सबसे पहले, ऐसा दृष्टिकोण मुझे पूरी तरह से स्पष्ट नहीं लग रहा था, पूरी तरह से "उपयुक्त" नहीं और बिल्कुल सामान्य नहीं था, लेकिन इस गेंद के विकास के एक साल बाद, मैं, इसके विपरीत, इस दृष्टिकोण का अनुयायी बन गया, और, इसके अलावा, मुझे अपनी परियोजनाओं में इसके लिए आवेदन मिला। ।

वापस लारवेल में।

DI Laravel एक "सर्विस कंटेनर" पर बनाया गया है - एक इकाई जो सिस्टम में बाइंडरों और निर्भरता का प्रबंधन करती है। इस प्रकार, हम, उदाहरण के लिए, DummyDataProviderInterface इंटरफ़ेस से ही इस DummyDataProvider इंटरफ़ेस के कार्यान्वयन का संकेत दे सकते हैं।

 app()->bind(DummyDataProviderInterface::class, DummyDataProvider::class); 

फिर, जब हम सेवा कंटेनर में DummyDataProviderInterface का अनुरोध करते हैं (उदाहरण के लिए, क्लास कंस्ट्रक्टर के माध्यम से), तो हमें DummyDataProvider वर्ग का एक उदाहरण मिलता है।

कई (किसी कारण से) लारवेल सेवा कंटेनर में इस ज्ञान को समाप्त करते हैं और अपनी खुद की, बहुत अधिक दिलचस्प चीजें करने के लिए जाते हैं, लेकिन व्यर्थ में ।

लारवेल न केवल वास्तविक संस्थाओं, जैसे कि किसी दिए गए इंटरफ़ेस, को "बाइंड" कर सकता है, बल्कि तथाकथित "आभासी प्रकार" (उर्फ उपनाम) भी बना सकता है। और, इस मामले में भी, लारवेल को एक वर्ग पास करने की ज़रूरत नहीं है जो आपके प्रकार को लागू करता है। बाइंड () विधि दूसरे तर्क के रूप में एक अनाम फ़ंक्शन ले सकती है, जिसमें $ ऐप पैरामीटर पास हुआ है - आवेदन वर्ग का एक उदाहरण। सामान्य तौर पर, अब हम अधिक प्रासंगिक बंधन में जा रहे हैं, जहां हम उस वर्ग से गुजरते हैं जो "आभासी प्रकार" को लागू करता है जो वर्तमान स्थिति पर निर्भर करता है।

मैं आपको चेतावनी देता हूं कि हर कोई एप्लिकेशन आर्किटेक्चर के निर्माण के इस दृष्टिकोण से सहमत नहीं है, इसलिए यदि आप एक ही वर्ग के सैकड़ों के प्रशंसक हैं, तो इस सामग्री को छोड़ दें।

तो, एक शुरुआत के लिए हम तय करेंगे कि "वास्तविक" वर्ग के रूप में क्या कार्य करेगा। एक कोड समीक्षा में मेरे सामने आई एक परियोजना के उदाहरण का उपयोग करते हुए, संसाधन अनुरोधों (वास्तव में, सीआरयूडी, लेकिन थोड़ा कट डाउन) के साथ एक ही स्थिति को लें।

आइए एक सामान्य क्रूड नियंत्रक के कार्यान्वयन को देखें:

 <?php namespace Wolf\Http\Controllers\Backend\Crud; use Illuminate\Database\Eloquent\Model; use Illuminate\Http\Request; use Wolf\Http\Controllers\Controller; class BaseController extends Controller { /** * @var Model */ protected $model; /** * @var \Illuminate\Http\Resources\Json\ResourceCollection|null */ protected $resourceCollection; /** * @var \Illuminate\Http\Resources\Json\JsonResource|null */ protected $jsonResource; /** * BaseController constructor. * @param Model $model * @param \Illuminate\Http\Resources\Json\ResourceCollection|null $resourceCollection * @param \Illuminate\Http\Resources\Json\JsonResource|null $jsonResource */ public function __construct( $model, $resourceCollection = null, $jsonResource = null ) { $this->model = $model; $this->resourceCollection = $resourceCollection; $this->jsonResource = $jsonResource; } /** * Display a listing of the resource. * * @param Request $request * @return \Illuminate\Http\Resources\Json\ResourceCollection */ public function index(Request $request) { return $this->resourceCollection::make($this->model->get()); } /** * Display the specified resource. * * @param int $id * @return \Illuminate\Http\Resources\Json\JsonResource */ public function show($id) { return $this->jsonResource::make($this->model->find($id)); } } 

मैं कार्यान्वयन के साथ ज्यादा परेशान नहीं हुआ, क्योंकि परियोजना वास्तव में योजना के स्तर पर है।

हमारे पास दो विधियां हैं जो हमें कुछ लौटाना चाहिए: सूचकांक, जो डेटाबेस से संस्थाओं का एक संग्रह लौटाता है, और दिखाता है, जो एक विशिष्ट इकाई के जोंस संसाधन को लौटाता है।

यदि हम वास्तविक कक्षाओं का उपयोग करते हैं, तो हर बार हम एक ऐसा वर्ग बनाएंगे जिसमें 1-2 बसने वाले मॉडल, संसाधन और संग्रह के लिए कक्षाएं परिभाषित होंगी। दर्जनों फाइलों की कल्पना करें, जिनमें से वास्तव में जटिल कार्यान्वयन केवल 1-2 है। हम डीआई लारवेल का उपयोग करके ऐसे "क्लोन" से बच सकते हैं।

तो, इस प्रणाली की वास्तुकला सरल होगी, लेकिन स्विस घड़ी के रूप में विश्वसनीय होगी।
एक json फ़ाइल है जिसमें कक्षाओं के प्रत्यक्ष संदर्भ के साथ "आभासी प्रकार" की एक सरणी होती है, जिसका उपयोग संग्रह, मॉडल, संसाधन, आदि के रूप में किया जाएगा ...

उदाहरण के लिए, यह:

 { "Wolf\\Http\\Controllers\\Backend\\Crud\\OrdersResourceController": { "model": "Wolf\\Model\\Backend\\Order", "resourceCollection": "Wolf\\Http\\Resources\\OrdersCollection", "jsonResource": "Wolf\\Http\\Resources\\OrderResource" } } 

इसके अलावा, Laravel बाइंडिंग का उपयोग करते हुए, हम वुल्फ \ Http \ Controllers \ Backend \ Crud \ BaseController को हमारे वर्चुअल प्रकार Wolf \ Http \ Controllers \ Backend \ Crud \ OrdersResourceController के रूप में लागू करने वाले वर्ग के रूप में सेट करेंगे (ध्यान दें कि वर्ग अमूर्त नहीं होना चाहिए, क्योंकि जब वुल्फ \ _ एचटीटीपी \ कंट्रोलर्स \ बैकेंड \ क्रूड \ ओडरस सोर्सकंट्रोलर के लिए अनुरोध किया जाता है तो हमें वुल्फ \ _ एचटीपीपी कंट्रोलर्स \ बैकेंड \ क्रूड \ बेसडंट्रोलर का एक उदाहरण मिलना चाहिए, न कि एक सार वर्ग)।

CrudServiceProvider में, बूट () विधि में, निम्न कोड डालें:

 $path = app_path('etc/crud.json'); if ($this->filesystem->isFile($path)) { $virtualTypes = json_decode($this->filesystem->get($path), true); foreach ($virtualTypes as $virtualType => $data) { $this->app->bind($virtualType, function ($app) use ($data) { /** @var Application $app */ $bindingData = [ 'model' => $app->make($data['model']), 'resourceCollection' => $data['resourceCollection'], 'jsonResource' => $data['jsonResource'] ]; return $app->makeWith(self::BASE_CRUD_CONTROLLER, $bindingData); }); } } 

निरंतर BASE_CRUD_CONTROLLER में उस वर्ग का नाम शामिल है जो CRUD नियंत्रक के तर्क को लागू करता है।

आदर्श से दूर, लेकिन यह काम करता है :)

यहां हम आभासी प्रकारों के साथ एक सरणी से गुजरते हैं और बाइंडरों को सेट करते हैं। ध्यान दें कि हम केवल सर्विस कंटेनर से मॉडल का उदाहरण प्राप्त करते हैं, और रिसोर्सकोलेशन और JsonResource सिर्फ क्लास के नाम हैं। ऐसा क्यों? मॉडल को भरने के लिए विशेषताओं में नहीं लेना पड़ता है, यह उनके बिना अच्छी तरह से कर सकता है। लेकिन संग्रह को किसी प्रकार के संसाधन में ले जाना चाहिए जिससे वे डेटा और इकाइयां प्राप्त करेंगे। इसलिए, बेसकंट्रोलर में हम क्रमशः स्टैटिक मेथड्स कलेक्शन () और मेक () का उपयोग करते हैं (सिद्धांत रूप में, हम डायनेमिक गेटर्स जोड़ सकते हैं जो संसाधन में कुछ डालेंगे और हमारे पास एक इंस्टेंस लौटाएंगे, लेकिन मैं आपको इसे छोड़ दूंगा) जो हमें इन उदाहरणों को वापस कर देगा। समान संग्रह, लेकिन उनके साथ स्थानांतरित किए गए डेटा के साथ।

वास्तव में, आप सिद्धांत रूप में, पूरे लारवेल को ऐसी स्थिति में बांध सकते हैं।

कुल मिलाकर, वुल्फ \ _ Http \ Controllers \ Backend \ Crud \ OrdersResontController का अनुरोध करते हुए हमें कंट्रोलर Wolf \ Http \ Controllers \ Backend \ Crud \ BaseController का एक उदाहरण मिलता है, लेकिन हमारे मॉडल, संसाधन और संग्रह की अंतर्निहित निर्भरता के साथ। यह केवल एक ResourceCollection और JsonResource बनाने के लिए बना हुआ है और आप लौटे डेटा को नियंत्रित कर सकते हैं।