2008-12-12 13 views
8

मैं जावा पृष्ठभूमि से आया हूं।अभी दृढ़ता के लिए सबसे अच्छा अभ्यास क्या है?

लेकिन मुझे लगातार ऑब्जेक्ट्स के लिए सर्वोत्तम अभ्यास माना जाने वाला क्रॉस-प्लेटफार्म परिप्रेक्ष्य चाहिए।

तरह से मैं इसे देख, वहाँ 3 शिविरों हैं:

  • ORM शिविर
  • प्रत्यक्ष क्वेरी शिविर उदा JDBC/डीएओ, iBatis
  • LINQ शिविर

क्या अभी भी लोगों handcode प्रश्नों (ORM को छोड़कर)? जेपीए, डीजेगो, रेल के माध्यम से उपलब्ध विकल्पों पर विचार क्यों करें।

उत्तर

6

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

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

इसके लिए कई कारण हैं जिनके लिए मैं यहां नहीं जाऊंगा, लेकिन यह कहने के लिए पर्याप्त है कि वे निर्णय हैं जो हमारी टीम के लिए काम करते हैं और हमारी टीम सहमत हैं। जो, दिन के अंत में, क्या मायने रखता है।

3

मैं वर्तमान में .NET में लगातार ऑब्जेक्ट्स पर पढ़ रहा हूं। इस तरह मैं एक सर्वोत्तम अभ्यास नहीं कर सकता, लेकिन शायद मेरी अंतर्दृष्टि आपको कुछ लाभ ला सकती है। कुछ महीने पहले तक मैंने हमेशा हाथ से पूछे जाने वाले प्रश्नों का उपयोग किया है, मेरे एएसपी.क्लासिक दिनों से एक बुरी आदत है।

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

इकाई फ्रेमवर्क - मैंने इसके साथ थोड़ा सा खेला और इसे पसंद नहीं आया। ऐसा लगता है कि मेरे लिए सब कुछ करना है और यह संग्रहित प्रक्रियाओं के साथ अच्छी तरह से काम नहीं करता है। ईएफ Linq2Entities का समर्थन करता है जो फिर से दृढ़ता से टाइप किए गए प्रश्नों की अनुमति देता है। मुझे लगता है कि यह एमएस एसक्यूएल तक ही सीमित है लेकिन मैं गलत हो सकता हूं।

सबसोनिक 3.0 (अल्फा) - यह सबसोनिक का एक नया संस्करण है जो लिंक का समर्थन करता है। SubSonic के बारे में अच्छी बात यह है कि यह टेम्पलेट फ़ाइलों (टी 4 टेम्पलेट्स, सी # में लिखा गया) पर आधारित है जिसे आप आसानी से संशोधित कर सकते हैं। इस प्रकार यदि आप ऑटो-जेनरेट कोड को अलग दिखाना चाहते हैं तो आप इसे बदल दें :)। मैंने अभी तक एक पूर्वावलोकन का प्रयास किया है लेकिन आज अल्फा देखेंगे। SubSonic 3 Alpha पर एक नज़र डालें। एमएस एसक्यूएल का समर्थन करता है लेकिन जल्द ही ओरेकल, माइस्क्ल इत्यादि का समर्थन करेगा।

अब तक मेरा निष्कर्ष Linq2SQL का उपयोग करना है जब तक सबसोनिक तैयार न हो और फिर उस पर स्विच करें क्योंकि सबसोनिक्स टेम्पलेट्स अधिक अनुकूलन की अनुमति देता है।

+0

पुन: ईएफ बॉक्स के बाहर एमएस एसक्यूएल तक सीमित है - हां, लेकिन तीसरे पक्ष के सहयोगी अन्य आरडीबीएमएस के लिए प्रदाताओं को विकसित कर रहे हैं। तो उदाहरण के लिए यदि आप ओरेकल चाहते हैं तो देवआर्ट नामक एक कंपनी के पास ओआरएसीईएल के लिए ईएफ प्रदाता और एक LINQ-to-ORACLE कार्यान्वयन भी है। – rohancragg

3

कम से कम एक और है: System Prevalence

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

तो, अक्सर, जवाब है: नौकरी के लिए विभिन्न प्रकार के औजारों को जानें, ताकि आप अपनी विशिष्ट स्थिति के लिए सबसे उपयुक्त उपयुक्त उपयोग कर सकें।

+0

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

2

सर्वोत्तम अभ्यास आपकी स्थिति पर निर्भर करता है।

यदि आपको किसी प्रकार की सार्थक संरचना के साथ तालिका संरचनाओं में डेटाबेस ऑब्जेक्ट्स की आवश्यकता है (इसलिए प्रति फ़ील्ड एक कॉलम, एक पंक्ति प्रति इकाई और इसी तरह) आपको ऑब्जेक्ट्स और डेटाबेस के बीच किसी प्रकार की अनुवाद परत की आवश्यकता होती है। दो शिविरों में ये गिरावट:

  • यदि डेटाबेस (बस भंडारण) में कोई तर्क है और टेबल अच्छी तरह से वस्तुओं के लिए नक्शे है, तो एक ORM समाधान एक त्वरित और विश्वसनीय हठ प्रणाली प्रदान कर सकते हैं। टॉपलिंक और हाइबरनेट जैसे जावा सिस्टम इस के लिए परिपक्व तकनीकें हैं।

  • अगर वहाँ डेटाबेस तर्क हठ में शामिल है, या अपने डेटाबेस स्कीमा अपने ऑब्जेक्ट मॉडल काफी से हो गए है, संग्रहित प्रक्रियाओं डेटा एक्सेस द्वारा लिपटे (आगे पैटर्न के साथ के रूप में आप की तरह) ऑब्जेक्ट्स ORM की तुलना में थोड़ा अधिक शामिल है लेकिन अधिक लचीला।

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

+0

पुन: पहला शिविर, मैं इस बात से सहमत नहीं हूं कि यह एक ओआरएम समाधान के साथ आसान है। इसे सही तरीके से काम करने के लिए निर्माण प्रणाली में बहुत सारे सेटअप हैं। – ashitaka

2

मैं अपना स्वयं का एसक्यूएल लिखना पसंद करता हूं, लेकिन जब मैं ऐसा करता हूं तो मैं अपनी सभी रिफैक्टरिंग तकनीक और अन्य "अच्छी चीजें" लागू करता हूं।

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

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

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

तो, एक सभ्य उदाहरण प्राप्त करने के तरीके के रूप में अपने किसी भी अभिव्यक्ति में एक ओआरएम उपकरण का उपयोग करें - देखें कि यह उत्पन्न होने वाले कई मुद्दों को कैसे हल करता है (मुख्य पीढ़ी, संघ, नेविगेशन, आदि)। अपने आउटपुट को अलग करें, इसे अपना बनाएं, फिर उस से बिल्ली का पुन: उपयोग करें।

+0

रोब, आपकी टिप्पणियों के लिए धन्यवाद। यह बहुत प्रबुद्ध है। मैं अपना स्वयं का एसक्यूएल लिखना भी पसंद करता हूं। लेकिन लगभग सभी परियोजनाओं में जो मैं प्रवेश करता हूं, वे एक ओआरएम का उपयोग करना पसंद करते हैं। आपके द्वारा उल्लिखित 40 मिलियन/दिन लेनदेन प्रणाली, यह किस प्लेटफॉर्म पर चल रहा था? – ashitaka

+0

8 टीबी ओरेकल 10 जी डेटाबेस पर सैन, सन सोलारिस 10, 4 जीबी रैम के साथ एक मिडलेवल सनफायर बॉक्स पर, जावा 1.6 जेबॉस और वेबलोगिक 10 पर वेब सेवा के माध्यम से खुला –

संबंधित मुद्दे