डिजाइन पैटर्न/डेटा लोडिंग समाधान

Question

मैं कुछ परियोजनाओं पर काम कर रहा हूं जिसमें डेटा लोड करना, कभी-कभी दूरस्थ रूप से, कभी-कभी स्थानीय, कभी-कभी JSON, कभी-कभी XML शामिल होता है। मेरी समस्या यह है कि विकास की गति और विभिन्न ग्राहकों के बदलते दिमाग के कारण मुझे लगता है कि मेरे डिजाइन बहुत कठोर हैं और मैं उन्हें अधिक लचीला होना चाहता हूं। मैं डेटा लोडिंग के पुन: प्रयोज्य समाधान के बारे में सोचने की कोशिश कर रहा हूं, और कुछ सलाह चाहूंगा क्योंकि मुझे लगता है कि आप में से कई को एक ही समस्या है।

मैं करना चाहते हैं क्या एक सामान्य LoadingOperation सार वर्ग है, जो प्रकार पार्सर और लोडर के सदस्य चर, जो पार्स() और loadData() पद्धतियों respectivly है है बनाने के लिए है। पार्सर और लोडर वर्गीकृत अंतरफलक और वर्गों को लागू इन कुछ इस तरह के साथ XMLParser और JSONParser, LocalLoader और RemoteLoader आदि हो सकता है मैं एक नया वर्ग है जो प्रत्येक बात के लिए LoadingOperation फैली से लोड करना होगा चाहते हैं , मौसम एक स्थानीय एक्सएमएल फ़ाइल, या दूरस्थ JSON, या जो कुछ भी है।

समस्या यह है कि विशिष्ट पार्सर कार्यान्वयन कस्टम डेटा प्रकार वापस नहीं लौट सकते LoadingOperation वर्ग के बहुरूपी व्यवहार को तोड़ने के बिना है। मैं चारों ओर जेनरिक के साथ की तरह

class SpecificLoader extends LoadingOperation<CustomDataType> 

LoadingOperation की उपवर्गों खिलवाड़ किया गया है और घोषित करने और पार्सर वर्गों के साथ इसी तरह की बातों कर रही है, लेकिन यह थोड़ा अजीब लगता है।

क्या किसी के पास कोई भी सुझाव है कि मैं क्या कर रहा हूं/बेहतर कर सकता हूं। मैं बदलते विनिर्देशों को जल्दी से प्रतिक्रिया करने में सक्षम होना चाहता हूं (इस तथ्य को अनदेखा कर रहा हूं कि उन्हें इतना बदलना नहीं चाहिए!) और कोड आदि का तार्किक पृथक्करण है ...

किसी भी मदद के लिए धन्यवाद!

संपादित करें: सवाल भी यहाँ link text

Answer 1

पूछा यह मेरे लिए लग रहा है कि तुम सच में कुछ है कि धीरे के रूप में मांगों को बहुत जल्दी बदल रहे हैं यथासंभव कम कोड के साथ लिखा गया चाहते हैं। यहां बताया गया है कि मैं अपनी परियोजना कैसे कर रहा हूं जहां मैं बैक एंड के लिए PHP का उपयोग करता हूं। मैं डाटाबेस से डेटा जल्दी से प्राप्त करने के लिए एसक्यूएल और जेसन का उपयोग करता हूं और क्लाइंट में लौटाता हूं।

आम तौर पर मैं प्रत्येक परिणाम पंक्ति के लिए डेटाबेस में एक चयन करता हूं, मैं पंक्ति को उस मानचित्र में रूपांतरित करता हूं जहां प्रत्येक कॉलम उस कॉलम के परिणाम के रूप में मूल्य के साथ कुंजी बन जाती है। नक्शे की यह सूची तब जेसन में जेनेरिक जेसन रूटिन के माध्यम से परिवर्तित की जाती है और जेसन सर्वर से भेजा जाता है।

इस तरह का सेटअप ग्राहक के लिए सर्वर से कुछ डेटा के परिवहन के लिए बहुत आसान है, लेकिन:

• आप ढीला प्रकार सुरक्षा है कि आप हाइबरनेट/xml/दूरस्थ का उपयोग करके मिल सकता है।
• आपके ग्राहक कड़ाई से आपके डेटाबेस स्कीमा के साथ मिलकर हैं।
• हालांकि डेटा को पकड़ने और परिवहन करने के लिए यह बुरा है।
• यदि आप अधिक डेटा प्राप्त करने के लिए क्वेरी बदलते हैं, तो ग्राहकों के किसी भी पुनर्मूल्यांकन की आवश्यकता नहीं होती है जब तक कि उन्हें नए डेटा का उपयोग करने की आवश्यकता न हो।

तुम ऐसा कैसे लगता है कि PHP में मुझे क्या करना की एक विचार देने के लिए:

मेरे डेटा का उपयोग वस्तु में:

function getAllPortal() { 
    $sql = "select firstname, lastname, U.* from person, portal_user U where id=person order by firstname, lastname"; 
    $prep = $this->db->prepare($sql); 
    return $prep->execute(); 
} 

और मेरे http सेवा में (आराम आधारित) कोड:

$accPerson = new AccountPerson($db); 
    echo json_encode($accPerson->getAllPortal()); 

जावा में ऐसा करने के लिए आपको शायद मानचित्रों की सूची में डेटा प्राप्त करने के लिए कुछ ढांचा बनाना होगा (या कुछ अन्य आसान संरचना जिसे आप परिवहन करना चाहते हैं ग्राहकों के लिए)। मैंने PHP में एक बनाया है जो ऐसा करता है जो तैयार बयानों के उपयोग की अनुमति देता है।

कुछ अन्य कारणों है कि आप विचार कर सकते हैं (भले ही आप के रूप में ऊपर नहीं करते) हो सकता है:

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

एक्सएमएल या यहां तक ​​कि बेहतर जेएसओएन के लिए अपने परिवहन के रूप में जाएं। स्कीमा के लिए न जाएं जो xml और serialization को pojos में बदलने का विरोध करता है। व्यवसाय तर्क के लिए Pojos महान है, लेकिन डेटा परिवहन के लिए बेकार है। यदि आपका ग्राहक पर्याप्त पतला है, तो अपने जेसन को ऑब्जेक्ट्स में फिर से बेकार न करें। सीधे जेएसओएन का प्रयोग करें। फिर, परतों के साथ, चाल यह जानना है कि pojos को पुनर्जीवित करने से व्यवसाय मूल्य मिलता है, और जब ऐसा नहीं होता है। परतों के साथ, उस कार्य को तब तक डालने का विरोध करें जब तक आप मूल्य नहीं देखते। Deserializers लिखना/बनाए रखना समय लगता है।