मॉडल क्लास बनाने या सामान्य डेटाबेस उपयोगिता वर्ग के साथ छड़ी बेहतर है?

हमारे डेटाबेस कॉल (एडीओ.NET के आस-पास एक हल्का आवरण) के लिए हमारे पास एक साधारण उपयोगिता कक्षा है, लेकिन मैं प्रत्येक डेटाबेस / ऑब्जेक्ट के लिए कक्षाएं बनाने की सोच रहा हूं। क्या ऐसा करने के लिए यह स्मार्ट बात होगी, या अगर हम एएसपी.नेट के लिए पूर्ण एमवीसी ढांचे का उपयोग कर रहे थे तो क्या इसका फायदा होगा?

तो हमारे पास यह है:

SQLWrapper.GetRecordset(connstr-alias, sql-statement, parameters);
SQLWrapper.GetDataset(connstr-alias, sql-statement, parameters);
SQLWrapper.Execute(connstr-alias, sql-statement, parameters);

ऐसा करने के बारे में सोच रहा है:

Person p = Person.get(id);
p.fname = "jon";
p.lname = "smith";
p.Save();

या एक नए रिकॉर्ड के लिए -

Person p = new Person();
p.fname = "Jon";
p.lname = "Smith";
p.Save();
p.Delete();

क्या यह स्मार्ट होगा, या यह अधिक हो जाएगा? मैं पुन: उपयोग, डेटाबेस बदलने और रखरखाव / पठनीयता के लिए लाभ देख सकता हूं।

0
जोड़ा संपादित
विचारों: 5

4 उत्तर

मेरे लिए ऐसा लगता है कि आप ऐसा करने की कोशिश कर रहे हैं जो LINQ आपके लिए पहले से ही कर सकता है। यदि आप पुराने फ्रेमवर्क में फंस गए हैं जिसमें आप इसका उपयोग नहीं कर सकते हैं, तो मैं सुझाव दे सकता हूं कि आप सबकोनिक ( http: // subsonicproject का उपयोग करें। com / ) हाथ से इन सभी मॉडल ऑब्जेक्ट्स मैन्युअल रूप से बनाने के बजाय।

मेरे पास एक प्रोजेक्ट था जहां मैं एक समान परिस्थिति में था और शानदार परिणाम के साथ आधे रास्ते में बदल गया। त्वरित विकास और कोड पढ़ने / उपयोग करने में बहुत आसान है।

0
जोड़ा
मैं लिंक लिखने के लिए लिंक से एसक्यूएल का परीक्षण कर रहा हूं, यह बहुत अच्छा है। ऐसा लगता है कि यह सरल मानचित्रण के लिए है, लेकिन यह मुझे आवश्यक किसी भी चीज़ के लिए पर्याप्त होना चाहिए। निश्चित रूप से कुछ जो उत्पन्न किया जाना चाहिए।
जोड़ा लेखक Steve Tranby, स्रोत

यह सवाल लोड किया गया है, डेटा संचालित डिजाइन बनाम डोमेन संचालित डिजाइन। किसी भी एप्लिकेशन के लिए जिसमें अच्छी मात्रा में व्यवहार है, तो डोमेन संचालित डिज़ाइन को प्राथमिकता दी जानी चाहिए। रिपोर्टिंग, या उपयोगिता अनुप्रयोग डेटा संचालित डिजाइन के साथ बेहतर काम करते हैं (या विकसित करने के लिए तेज़ होते हैं)।

आप जो पूछ रहे हैं वह है "क्या मेरी कंपनी को हमारे कोड को डिजाइन करने में मौलिक बदलाव करना चाहिए"। एक डोमेन-सनकी के रूप में, मेरी आंत प्रतिक्रिया yes चीखना है। हालांकि, आपके प्रश्न की सरल प्रकृति से, मुझे यकीन नहीं है कि आप जो परिवर्तन प्रस्तावित कर रहे हैं उसके दायरे को पूरी तरह समझते हैं। मुझे लगता है कि आपको इसके बारे में अपनी टीम से और बात करनी चाहिए।

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

0
जोड़ा
जानकारी के लिए धन्यवाद, मैं उन पुस्तकों को देख लूंगा। क्षमा करें मेरा प्रश्न लोड / सरल था। मैं बहुत ज्यादा लिखना नहीं चाहता था, और संभवतः मॉडल बनाम नो-मॉडल के बारे में पूछा जाना चाहिए था। मेरी टीम के साथ समस्या यह है कि मैं यहां नया हूं, और वे बहुत सारे चल रहे हैं और विरासत क्लासिक-एएसपी कोड की बहुत सारी विरासत हैं, साथ ही वे एएसपी.Net की कुछ सुविधाओं का उपयोग करते समय भी उस तरह से विकसित होते हैं। (पहले इसे उत्तर के रूप में उत्तर दिया, जिसे समुदाय नियमों के अनुसार हटा दिया गया था)
जोड़ा लेखक Steve Tranby, स्रोत

एमवीसी वेब के लिए एकमात्र डिजाइन पैटर्न नहीं है, लेकिन यह एक उपयोगी है।

केवल 'एम' को अपनाने से मेरी राय में लाभांश का भुगतान होगा, भले ही आप 'वी' या 'सी' को अपनाना नहीं चाहें।

0
जोड़ा
इनपुट के लिए धन्यवाद, मुझे लगता है कि मैं इसे 'एम' जोड़ना / बदलना शुरू कर दूंगा! (पहले उत्तर के रूप में उत्तर दिया गया था, जिसे समुदाय नियमों के अनुसार हटा दिया गया था)
जोड़ा लेखक Steve Tranby, स्रोत

जिस दृष्टिकोण पर आप चर्चा करते हैं उसे कई लोगों द्वारा अच्छा माना जाता है, मुझे शामिल किया गया! इस दृष्टिकोण को सीखने के लिए कुछ प्रयास की आवश्यकता होगी, लेकिन इसे आपको छोड़ने न दें!

LINQ से SQL के साथ छोटी परियोजना को बस कोशिश करने के बारे में क्या? शायद अच्छा संदर्भ प्रोजेक्ट ढूंढें .com "rel =" nofollow noreferrer "> Google code , और अध्ययन करें कि दूसरों ने इसके साथ कैसे काम किया है।

यह एक साधारण टूल है, और आपको डेटाबेस में मैपिंग ऑब्जेक्ट्स के साथ आने वाले कुछ मुद्दों से परिचित होने देगा।

इसके बाद आप इसके लिए एक महसूस कर सकते हैं , और यह तय कर सकते हैं कि यह सीखने की अवस्था के लायक है या नहीं।

There will be new concepts to grasp and experiment with, things like:

  • Unit of Work: When you execute Save and Delete etc, an ORM tends to not do this immediately, whereas a recordset based DAL will. This can be surprising so you'll need to learn a bit about that. Read up on the Unit of Work pattern to get an understanding of this.
  • Bulk Operations are an issue with OR/M. A data reader can efficiently iterate through thousands of rows, but with an ORM you have to be careful when working with large batches of objects. Again, one to read up on.
  • Associations seem great when can do stuff like customer.Orders.Count but they are also the cause of many problems. You'll need to find some safe practices to follow when working with associations.

...कुछ नाम है।

शुरुआत के लिए, विरासत और सामान के बारे में चिंता न करें, बस सरल शुरू करें और सरल इकाइयां रखें जो टेबल पर मैप करें।

उसी तरह उनका उपयोग करने का प्रयास करें जैसे आप अपने मौजूदा डीएएल का उपयोग करेंगे। फिर संघों के साथ प्रयोग करना शुरू करें।

तो शायद अपनी संस्थाओं में अधिक व्यवहार डालने का प्रयास करें। यदि आप इसे पसंद करना शुरू करते हैं, और आपको लगता है कि आपको और अधिक सुविधाएं चाहिए, तो अधिक सुविधा युक्त ओआरएम को लाइटस्पीड या NHibernate

उम्मीद है की यह मदद करेगा!

0
जोड़ा