कृपया एलोकेंट के साथ रिपॉजिटरी टेम्पलेट के बारे में बात करना बंद करें

मैं नियमित रूप से "एलोकेंट के साथ रिपॉजिटरी टेम्पलेट का उपयोग कैसे करें" की शैली में लेख देखता हूं (जिनमें से एक हाल ही में PHP डाइजेस्ट में मिला है )। उनकी सामान्य सामग्री: चलो एक इंटरफ़ेस बनाते हैं PostRepositoryInterface , EloquentPostRepository वर्ग, अच्छी तरह से उन्हें निर्भरता कंटेनर में बाँधते हैं और मानक Ekovent विधियों के बजाय सहेजें और ढूँढें का उपयोग करते हैं।

इस टेम्प्लेट की आवश्यकता क्यों है कभी-कभी वे बिल्कुल नहीं लिखते हैं ("यह एक टेम्प्लेट है ! यह पर्याप्त नहीं है!"), कभी-कभी वे संभावित डेटाबेस परिवर्तन (प्रत्येक परियोजना में एक बहुत ही सामान्य घटना), साथ ही परीक्षण और मोचा-स्टब्स के बारे में कुछ लिखते हैं। इस तरह के लेख में एक नियमित लारवेल परियोजना में इस तरह के टेम्पलेट को पेश करने के लाभों को पकड़ना मुश्किल है।

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

एलोकेंट रिपोजिटरी के उदाहरणों को दो प्रकारों में विभाजित किया गया है:

1. दोहरी सुवक्ता-सरणी भिन्नता
2. शुद्ध वाक्पटु भंडार

दोहरी सुवक्ता-सरणी भिन्नता

पहले का एक उदाहरण (एक यादृच्छिक लेख से लिया गया):

<?php interface FaqRepository { public function all($columns = array('*')); public function newInstance(array $attributes = array()); public function paginate($perPage = 15, $columns = array('*')); public function create(array $attributes); public function find($id, $columns = array('*')); public function updateWithIdAndInput($id, array $input); public function destroy($id); } class FaqRepositoryEloquent implements FaqRepository { protected $faqModel; public function __construct(Faq $faqModel) { $this->faqModel = $faqModel; } public function newInstance(array $attributes = array()) { if (!isset($attributes['rank'])) { $attributes['rank'] = 0; } return $this->faqModel->newInstance($attributes); } public function paginate($perPage = 0, $columns = array('*')) { $perPage = $perPage ?: Config::get('pagination.length'); return $this->faqModel ->rankedWhere('answered', 1) ->paginate($perPage, $columns); } public function all($columns = array('*')) { return $this->faqModel->rankedAll($columns); } public function create(array $attributes) { return $this->faqModel->create($attributes); } public function find($id, $columns = array('*')) { return $this->faqModel->findOrFail($id, $columns); } public function updateWithIdAndInput($id, array $input) { $faq = $this->faqModel->find($id); return $faq->update($input); } public function destroy($id) { return $this->faqModel->destroy($id); } } 

सभी , पाते हैं , पृष्ठबद्ध तरीके लौकिक वस्तुएं लौटाते हैं, हालांकि, बनाते हैं , अद्यतन करें। IndAndInput एक सरणी की प्रतीक्षा कर रहे हैं।

नाम updateWithIdAndInput का अर्थ है कि यह "रिपॉजिटरी" केवल CRUD ऑपरेशन के लिए उपयोग किया जाएगा।

कोई सामान्य व्यावसायिक तर्क अपेक्षित नहीं है, लेकिन हम सबसे सरल लागू करने का प्रयास करेंगे:

 <?php class FaqController extends Controller { public function publish($id, FaqRepository $repository) { $faq = $repository->find($id); //...-   $faq->... $faq->published = true; $repository->updateWithIdAndInput($id, $faq->toArray()); } } 

और अगर एक भंडार के बिना:

 <?php class FaqController extends Controller { public function publish($id) { $faq = Faq::findOrFail($id); //...-   $faq->... $faq->published = true; $faq->save(); } } 

दो बार आसान।

क्यों परियोजना में एक अमूर्तता का परिचय दें जो केवल इसे जटिल करेगा?

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

शुद्ध वाक्पटु भंडार

केवल एलोकेंट के साथ काम के साथ एक भंडार का एक उदाहरण (एक लेख में भी पाया गया):

 <?php interface PostRepositoryInterface { public function get($id); public function all(); public function delete($id); public function save(Post $post); } class PostRepository implements PostRepositoryInterface { public function get($id) { return Post::find($id); } public function all() { return Post::all(); } public function delete($id) { Post::destroy($id); } public function save(Post $post) { $post->save(); } } 

मैं इस लेख में अनावश्यक प्रत्यय इंटरफ़ेस को नहीं डांटूंगा।

यह कार्यान्वयन थोड़ा अधिक है जैसा कि टेम्पलेट विवरण कहता है।

सबसे सरल तर्क का कार्यान्वयन थोड़ा अधिक स्वाभाविक लगता है:

 <?php class FaqController extends Controller { public function publish($id, PostRepositoryInterface $repository) { $post = $repository->find($id); //...-   $post->... $post->published = true; $repository->save($post); } } 

हालाँकि, सरलतम ब्लॉग पोस्टों के लिए भंडार को लागू करना बच्चों के लिए एक खिलौना है।

चलो कुछ और अधिक जटिल प्रयास करें।

उप-संस्थाओं के साथ एक साधारण इकाई। उदाहरण के लिए, संभावित उत्तर के साथ एक सर्वेक्षण (साइट पर या चैट में नियमित मतदान)।

इस तरह के सर्वेक्षण का उद्देश्य बनाने का मामला। दो विकल्प:

• PollRepository और PollOptionRepository बनाएं और दोनों का उपयोग करें।
  इस विकल्प के साथ समस्या यह है कि अमूर्त ने काम नहीं किया।
  संभावित उत्तरों के साथ एक सर्वेक्षण एक इकाई है और डेटाबेस में इसके भंडारण को एक पोलरपोसिटरी क्लास द्वारा लागू किया जाना चाहिए।
  PollOptionRepository :: हटाना आसान नहीं होगा, क्योंकि उसे यह समझने के लिए पोल ऑब्जेक्ट की आवश्यकता होगी कि क्या यह उत्तर विकल्प हटाया जा सकता है (क्योंकि यदि पोल में केवल एक ही विकल्प है तो वह पोल नहीं होगा)।
  और रिपॉजिटरी टेम्पलेट रिपॉजिटरी के अंदर व्यावसायिक तर्क के कार्यान्वयन का मतलब नहीं है।
• पोलरिपॉजिटरी के अंदर सेवऑप्शन और डिलीटओशन मेथड जोड़ें।
  समस्याएं लगभग समान हैं। भंडारण से अमूर्तता किसी तरह का निकम्मापन बन जाती है ... उत्तर विकल्पों को अलग से लेने की आवश्यकता होती है।
  लेकिन क्या होगा अगर सार और भी जटिल है? अन्य उपजातियों के एक समूह के साथ?

एक ही सवाल उठता है: यह सब क्यों है?
स्टोरेज सिस्टम से अधिक अमूर्तता प्राप्त करें जो एलोकेंट देता है - काम नहीं करेगा।

इकाई परीक्षण?

यहाँ मेरी पुस्तक से संभावित इकाई परीक्षण का एक उदाहरण दिया गया है - https://gist.github.com/adelf/a53ce49b22b32914879801113cf79043
सरल ऑपरेशन के लिए इतनी बड़ी इकाई परीक्षण करना किसी के लिए आनंद लेने के लिए पर्याप्त नहीं है।

मुझे लगभग यकीन है कि परियोजना में ऐसे परीक्षणों को छोड़ दिया जाएगा।

कोई उनका समर्थन नहीं करना चाहता। मैं इस तरह के परीक्षण के साथ एक परियोजना पर था, मुझे पता है।

कार्यात्मक परीक्षण पर ध्यान केंद्रित करना बहुत आसान और अधिक सही है।
खासकर अगर यह एक एपीआई परियोजना है।

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

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