विभिन्न इकाई-श्रेणियों के लिए अलग-अलग इकाई-गुणों को कैसे संभालें

Question

मुझे समस्या का सामना करना पड़ रहा है, जिसे प्रोग्रामर.स्टैक एक्सचेंज डॉट कॉम पर भी रखा जा सकता है, लेकिन चूंकि यह सिद्धांत और जेडएफ 2 से काफी जुड़ा हुआ है, इसलिए मैंने इसे ऊपर रखना चुना यहा पर। मुझे आपको अपने परिदृश्य में पेश करने दें:

• मेरे पास एक ऐसा एप्लिकेशन है जहां उपयोगकर्ता संस्थाएं पोस्ट करते हैं (BaseEntity)।
• BaseEntity संपत्ति $cagetory
• $category पर निर्भर करता है इकाई हालांकि अतिरिक्त गुण
होना आवश्यक है है

अब सरल उदाहरण:

class BaseEntity { 
    protected $id; 
    protected $title; 
    protected $description; 
} 

class MovieEntity { 
    protected $id; 
    protected $title; 
    protected $description; 
    protected $airingDateStart; // new property 
    protected $airingDateEnd; // new property 
} 

अब मैं आसानी से एक दो कदम फ़ॉर्म्यूलर कर सकता है जहां उपयोगकर्ता पहले अपनी श्रेणी चुनता है और उस पर निर्भर करता है कि EntityClass चुना जाएगा - लेकिन मेरे पास यह नहीं हो सकता है। लेकिन यह अच्छा नहीं है क्योंकि क्या होगा यदि उपयोगकर्ता BaseEntity-श्रेणी में मूवी डालता है और फिर बाद में इकाई को MovieEntity में बदलना चाहता है? तो यह विचार वास्तव में एक सुरक्षित विकल्प नहीं है।

अतिरिक्त आवश्यकताओं (सामान और अधिक जटिल बनाने के लिए)

• श्रेणियाँ के साथ ही संस्थाओं सिद्धांत द्वारा नियंत्रित किया जा है
• प्रत्येक Category एक भी Module
• के माध्यम से आवेदन करने के लिए प्रदान की जाती है मॉड्यूल को बिना किसी कॉन्फ़िगरेशन के अनुप्रयोग में रखा जाना चाहिए (CategoryTable को पॉप्युलेट करने के लिए अधिकतम एक डीबी-क्वेरी पर)

मैं तो क्या अब तक

पहले तो मैं सिद्धांत कार्यक्षमता एकल टेबल विरासत साथ चलाने के लिए चुना है। इसने मुझे MovieEntity extends BaseEntity जैसी चीजों को आसानी से करने की अनुमति दी और चीजें डाटाबेस में नई इकाइयों को जोड़ने के लिए आकर्षण की तरह काम करती हैं। लेकिन मुख्य समस्या बनी हुई है: यदि उपयोगकर्ता श्रेणी बदलता है, तो यह EntityClass को बदल देगा और यह बहुत अधिक नो-गो है।

मेरा मतलब है हाँ, मैं अपने वर्तमान तरीके से चीजों को कर सकता हूं और श्रेणी के परिवर्तन पर DiscriminatorColumn मैन्युअल रूप से संशोधित कर सकता हूं लेकिन यह बहुत ही गंदा है।

एक और वैकल्पिक दृष्टिकोण यह होगा कि श्रेणी बदलने की स्थिति पर, एक नई इकाई बनाई जाएगी और पुराना व्यक्ति नष्ट हो जाएगा, लेकिन यह भी गंदा लगता है।

सब कुछ मुझे लगता है कि मैं गलत दिशा में आगे बढ़ रहा हूं। एक विकास-पैटर्न हो सकता है जिसके बारे में मुझे नहीं पता है कि मेरा सख्त काम कचरे की तरह दिखता है और चीजें अंत में सुपर आसान हो जाती हैं, लेकिन ऐसा लगता है कि मैं सामानों को देख रहा हूं।

शायद मैं क्या कर रहा हूँ के लिए साइन अप के करीब आइडिया पाने के लिए आपको GitHub पर अपने आवेदन पर एक नजर है हो सकता है:

• DuitMarketplace - यह एक आधार वर्ग के साथ मुख्य आवेदन, सभी है नियंत्रक, आदि ...ItemController#editAction() कुछ और संकेत प्रदान कर सकता है कि मैं कुछ चीजों को स्वचालित करने का इरादा रखता हूं।
• DuitMarketplaceItemVehicle - एक वर्ग है कि के मिल mainapp में

अग्रिम धन्यवाद में सभी प्रतिक्रिया मैं मिल सकता है के लिए गिरा दिया। मुझे पूरी तरह से एहसास है कि यह प्रश्न शायद एसओ बनाम प्रोग्रामर.स्टैक एक्सचेंज पर मौजूद एक अस्तित्व के बीच सीमा रेखा है, लेकिन मैंने इसे सब कुछ के बाद यहां चुना है।

Answer 1

मैं अपनी स्थिति सही पढ़ रहा हूँ, तो ऐसा लगता है कि आप बेहतर के बारे में बातें और श्रेणियाँ बीच संबंध के गुणों के रूप में श्रेणी-विशिष्ट विशेषताओं बात बात पर विरासत से बचने, और बदले द्वारा सेवा होगी लगता है।

क्या इस तरह एक वास्तुकला के बारे में:

<?php 

class Category { 
    protected $id; 
    protected $title; 
    protected $things; //@ManyToOne(targetEntity="ThingCategory") 
} 

class Thing { 
    protected $id; 
    protected $title; 
    protected $description; 
    protected $category; //@ManyToOne(targetEntity="ThingCategory") 
}  

/** 
* Use [Single|Class]-Table Inheritence to model subject-category attributes. 
* 
* ThingCategory is just a base class. Modules provide concrete subclasses 
* that encapsulate category-specific attributes. 
*/ 
class ThingCategory { 
    protected $id; //surrogate key, not strictly necessary 
    protected $thing; //@ManyToOne(targetEntity="Thing") 
    protected $category //@ManyToOne(targetEntity="Category") 
} 

class ThingMovieCategory extends ThingCategory{ 
    protected $airingStartDate; 
    protected $airingEndDate; 
} 

class ThingCarCategory extends ThingCategory { 
    protected $horespower; 
    protected $numberOfDoors; 
    protected $color; 
} 

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

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

Answer 2

आपकी समस्या इस वाक्य है "लेकिन मुख्य समस्या बनी हुई है:। उपयोगकर्ता दृश्य बदल जाता है, तो श्रेणी, यह EntityClass बदल जाएगा और कहा कि काफी एक नो-जाओ है"

एक वर्ग वास्तव में नहीं बदल जाएगा, इसे हटा दिया जाएगा, और एक नया एक के साथ बदल दिया। तो इसे अपने कोड में प्रतिबिंबित करें, एक नई इकाई बनाएं, इसे जारी रखें, नई इकाई को इंगित करने के लिए सभी संदर्भ अपडेट करें, और फिर पुरानी इकाई को हटा दें।