इससे पहले कि मैं प्रश्न का उत्तर दूं, मुझे लगता है कि कुछ पृष्ठभूमि क्रम में है।
समस्या का मूल
डेवलपर्स के साक्षात्कार और काम पर रखने के वर्षों के बाद, मैंने दो चीजें सीखी हैं:
डेवलपर्स के विशाल बहुमत को डेटाबेस डिजाइन में बहुत कम अनुभव है।
मैंने उन लोगों के बीच एक ढीला सहसंबंध देखा है जो डेटाबेस को नहीं समझते हैं और जो ओआरएम से नफरत करते हैं।
(नोट: और हाँ, मुझे पता है कि ऐसे लोग हैं जो डेटाबेस को अच्छी तरह समझते हैं जो ORM से नफरत करते हैं)
जब लोगों को समझ में नहीं आता क्यों विदेशी कुंजी कारण है कि आप में निर्माता नाम एम्बेड न करें, महत्वपूर्ण हैं itemतालिका, या क्यों customer.address1, customer.address2है, और customer.address3क्षेत्रों में एक अच्छा विचार लिखने डेटाबेस कीड़े को यह उनके लिए आसान बनाने के लिए एक ORM जोड़ने नहीं हैं, कुछ भी मदद करने के लिए नहीं जा रहा है।
इसके बजाय, ठीक से डिज़ाइन किए गए डेटाबेस और एक ओएलटीपी उपयोग के मामले के साथ, ओआरएम सुनहरे हैं। ग्रंट का अधिकांश काम चला जाता है और डीबीआईएक्स :: क्लास :: स्कीमा :: लोडर जैसे टूल के साथ , मैं एक अच्छे डेटाबेस स्कीमा से काम करने वाले पर्ल कोड तक मिनटों में जा सकता हूं। मैं पेरेटो नियम का हवाला देता हूं और कहता हूं कि मेरी 80% समस्याओं को 20% काम के साथ हल कर दिया गया है, लेकिन वास्तव में, मुझे इससे भी अधिक लाभ मिलता है।
समाधान का दुरुपयोग
एक और कारण है कि कुछ लोग ORM से नफरत करते हैं क्योंकि वे अमूर्त रिसाव होने देंगे। आइए MVC वेब ऐप्स के सामान्य मामले पर विचार करें। यहां कुछ ऐसा है जो हम आमतौर पर देखते हैं (छद्म कोड):
GET '/countries/offices/$company' => sub {
my ( $app, $company_slug ) = @_;
my $company = $app->model('Company')->find({ slug => $company_slug })
or $app->redirect('/');
my $countries = $app->model('Countries')->search(
{
'company.company_id' => $company->company_id,
},
{
join => [ offices => 'company' ],
order_by => 'me.name',
},
);
$app->stash({
company => $company,
countries => $country,
});
}
लोग इस तरह नियंत्रक मार्ग लिखते हैं और खुद को पीठ पर थपथपाते हुए सोचते हैं कि यह अच्छा है, साफ कोड है। वे अपने नियंत्रकों में हार्ड-कोडिंग एसक्यूएल पर सहमत होंगे, लेकिन उन्होंने एक अलग एसक्यूएल सिंटैक्स को उजागर करने की तुलना में थोड़ा अधिक किया है। उनके ORM कोड को एक मॉडल में नीचे धकेल दिया जाना चाहिए और फिर वे ऐसा कर सकते हैं:
GET '/countries/offices/$company' => sub {
my ( $app, $company_slug ) = @_;
my $result = $app->model('Company')->countries($company_slug)
or $app->redirect('/');
$app->stash({ result => $result });
}
तुम्हें पता है कि अब क्या हुआ है? आपने अपने मॉडल को ठीक प्रकार से समझाया है, आपने ORM को उजागर नहीं किया है, और बाद में, जब आप पाते हैं कि आप डेटाबेस के बजाय कैश से उस डेटा को प्राप्त कर सकते हैं, तो आपको अपना नियंत्रक कोड बदलने की आवश्यकता नहीं है (और यह आसान है) इसके लिए परीक्षण लिखना और तर्क का पुन: उपयोग करना)।
वास्तव में, ऐसा क्या होता है कि लोग अपने नियंत्रकों (और विचारों) पर ओआरएम कोड को लीक कर देते हैं और जब वे स्केलेबिलिटी मुद्दों को मारते हैं, तो वे अपनी वास्तुकला के बजाय ओआरएम को दोष देना शुरू कर देते हैं। ओआरएम को एक बुरा रैप मिलता है (मैं कई ग्राहकों के लिए इसे बार-बार देखता हूं)। इसके बजाय, उस अमूर्त को छिपाएं, ताकि जब आप ORM की सीमा से टकराएं, तो आप अपनी समस्या के लिए उपयुक्त समाधान चुन सकें, बजाय इसके कि कोड को ORM से इतना कस कर जोड़ा जाए कि आप हग-बंध हो जाएं।
रिपोर्टिंग और अन्य सीमाएँ
जैसा कि रोब कियोन ने ऊपर स्पष्ट किया है, रिपोर्ट करना ओआरएम में कमजोरी है। यह एक बड़ी समस्या का एक सबसेट है जहाँ जटिल एसक्यूएल या एसक्यूएल जो कई तालिकाओं को फैलाते हैं कभी-कभी ओआरएम के साथ अच्छी तरह से काम नहीं करते हैं। उदाहरण के लिए, कभी-कभी ORM एक सम्मिलित प्रकार को बाध्य करता है जो मैं नहीं चाहता और मैं यह नहीं बता सकता कि इसे कैसे ठीक किया जाए। या हो सकता है कि मैं MySQL में एक सूचकांक संकेत का उपयोग करना चाहता हूं , लेकिन यह आसान नहीं है । या कभी-कभी एसक्यूएल केवल इतना जटिल जटिल होता है कि यह एब्सट्रैक्ट प्रदान करने के बजाय एसक्यूएल लिखना अच्छा होगा।
यह उस कारण का हिस्सा है जिसे मैंने DBIx :: Class :: Report लिखना शुरू किया है । अब तक यह अच्छी तरह से काम करता है और लोगों के अधिकांश मुद्दों को यहां हल करता है (जब तक कि वे केवल पढ़ने के लिए इंटरफ़ेस के साथ ठीक हैं)। और जब यह एक बैसाखी की तरह लगता है, वास्तविकता में, तो जब तक आप अपने अमूर्त को लीक नहीं कर रहे हैं (जैसा कि पिछले भाग में बताया गया है), तो यह और DBIx::Classभी आसान काम करता है।
तो मैं कब DBIx :: क्लास चुनूंगा?
मेरे लिए, मैं इसे ज्यादातर बार चुनूंगा कि मुझे एक डेटाबेस के लिए एक इंटरफ़ेस की आवश्यकता है। मैं वर्षों से इसका उपयोग कर रहा हूं। हालाँकि, मैं इसे OLAP सिस्टम के लिए नहीं चुन सकता, और नए प्रोग्रामर निश्चित रूप से इसके साथ संघर्ष करने जा रहे हैं। इसके अलावा, मुझे अक्सर लगता है कि मुझे मेटा-प्रोग्रामिंग की आवश्यकता है और DBIx::Classउपकरण प्रदान करते समय , वे बहुत खराब दस्तावेज हैं।
DBIx::Classसही ढंग से उपयोग करने की कुंजी अधिकांश ORM के समान है:
अमूर्त रिसाव मत करो।
अपने शापित परीक्षण लिखें।
आवश्यकतानुसार एसक्यूएल को नीचे जाने का तरीका जानें।
डेटाबेस को सामान्य करने का तरीका जानें।
DBIx::Class, एक बार जब आप इसे सीख लेते हैं, तो आप के लिए अपने अधिकांश भारी उठाने का ध्यान रखेंगे और इसे जल्दी से आवेदन लिखने के लिए एक हवा बनाते हैं।