हम लाभ के साथ लक्षण का उपयोग करते हैं

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

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

namespace Column; trait Id { /** * @var integer * @ORM\Id * @ORM\Column(type="integer") * @ORM\GeneratedValue(strategy="AUTO") */ protected $id; /** * @return integer */ public function getId() { return $this->id; } } 

अब, अगले मॉडल का वर्णन करते हुए, यह हमारे लिए 15 के बजाय एक पंक्ति में प्रवेश करने के लिए पर्याप्त है।

 class Book { use \Column\Id; } 

क्या यह महान नहीं है?

जब इस तरह का एक विचार मेरे पास आया - मैंने जाने-माने KNPLabs से कुछ पुस्तकालयों को पाया।

• github.com/KnpLabs/DoctrineBehaviors
• github.com/KnpLabs/ControllerBehaviors

सब कुछ काफी सरल है कि कैसे उपयोग किया जाए - README में वर्णित है।

हालाँकि, ये लाइब्रेरी तर्क की पूरी मात्रा को जोड़ते हैं, और मैं मॉडल कोड को छोटा करना चाहूंगा।
इसलिए, मैंने अपनी परियोजना में उपयोग किए गए अधिकांश लक्षणों को एक अलग सिद्धांत-कॉलम में डाल दिया।
पुस्तकालय अब मॉडल कक्षाओं में अक्सर उपयोग की जाने वाली संपत्तियों का एक छोटा सा सेट है।
आइए Book जोड़ें।

 use Nkt\Column; class Book { use Column\Id; use Column\Name; use Column\Price; use Column\Description; use Column\CreatedDate; public function __construct($name, $description) { $this->setName($name); $this->setDescription($description); $this->setCreatedDate(new \DateTime()); } } 

अब आप कुछ अद्वितीय गुणों को जोड़ सकते हैं, कुछ प्रकार के तर्क का वर्णन कर सकते हैं, लेकिन मॉडल कोड फूला नहीं होगा।

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

हालांकि, सब कुछ इतना रसीला नहीं है - एक छोटी सी समस्या है। यदि डेटा स्कीम को एनोटेशन से लिया जाता है, तो इसे स्ट्रिक्ट स्टैंडआर्ट्स चेतावनी के बिना फिर से परिभाषित नहीं किया जा सकता है।

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