हाल ही में उन ऐप्स में जो मैं विकसित कर रहा हूं, मैं डेटाबेस में एक सम्मिलित, अद्यतन, हटाए गए पंक्तियों की संख्या की जांच कर रहा हूं और यदि नंबर अप्रत्याशित है तो त्रुटि दर्ज कर रहा है। उदाहरण के लिए, एक पंक्ति के सरल डालने, अपडेट करने या हटाने पर, यदि किसी एक से अधिक पंक्तियों को ExecuteNonQuery() कॉल से वापस किया जाता है, तो मैं उस त्रुटि पर विचार करूंगा और इसे लॉग कर दूंगा। साथ ही, मुझे अब एहसास है क्योंकि मैं यह टाइप करता हूं कि यदि लेनदेन को तोड़ने की कोशिश भी नहीं होती है, तो यह सबसे अच्छा अभ्यास नहीं है और निश्चित रूप से संबोधित किया जाना चाहिए।डेटाबेस कार्रवाई (सम्मिलित, अद्यतन, हटाएं) ओवरकिल के बाद पंक्तियों को प्रभावित करने वाली पंक्तियों की जांच कर रहा है?
मैं डेटा स्तर समारोह db करने के लिए कॉल करता है कि होगा: वैसे भी, यहाँ वर्णन करने के लिए मैं क्या मतलब कोड है
public static int DLInsert(Person person)
{
Database db = DatabaseFactory.CreateDatabase("dbConnString");
using (DbCommand dbCommand = db.GetStoredProcCommand("dbo.Insert_Person"))
{
db.AddInParameter(dbCommand, "@FirstName", DbType.Byte, person.FirstName);
db.AddInParameter(dbCommand, "@LastName", DbType.String, person.LastName);
db.AddInParameter(dbCommand, "@Address", DbType.Boolean, person.Address);
return db.ExecuteNonQuery(dbCommand);
}
}
फिर डेटा परत कार्य करने के लिए एक व्यापार परत कॉल:
public static bool BLInsert(Person person)
{
if (DLInsert(campusRating) != 1)
{
// log exception
return false;
}
return true;
}
और कोड-पीछे या ध्यान में रखते हुए (मैं क्या दोनों webforms और MVC परियोजनाओं):
if (BLInsert(person))
{
// carry on as normal with whatever other code after successful insert
}
else
{
// throw an exception that directs the user to one of my custom error pages
}
जितना अधिक मैं इस प्रकार के कोड का उपयोग करता हूं, उतना ही मुझे लगता है कि यह अधिक है। विशेष रूप से कोड-पीछे/दृश्य में। क्या सरल डालने, अपडेट करने या हटाने के लिए कोई वैध कारण डेटाबेस में पंक्तियों की सही संख्या को वास्तव में संशोधित नहीं करेगा? क्या यह केवल वास्तविक एसक्लएक्सप्शन को पकड़ने और फिर इसे संभालने के बारे में चिंता करने के लिए अधिक व्यावहारिक है, हर बार प्रभावित पंक्तियों के लिए एकान्त जांच करने के बजाय?
धन्यवाद। आशा है कि आप सभी मेरी मदद कर सकते हैं।
अद्यतन
धन्यवाद समय जवाब देने के लिए समय निकालने के लिए हर किसी को। मैंने अभी भी 100% तय नहीं किया है कि मैं किस सेटअप का आगे बढ़ने का उपयोग करूंगा, लेकिन यहां मैंने आपके सभी प्रतिक्रियाओं से दूर ले लिया है।
- एक क्वेरी को संभालने के लिए डीबी और नेट पुस्तकालयों पर भरोसा करें और उन्हें अपना काम करने के लिए डिज़ाइन किया गया है।
- किसी भी त्रुटि पर क्वेरी को रोलबैक करने के लिए मेरी संग्रहीत प्रक्रियाओं में लेनदेन का उपयोग करें और संभावित रूप से
raiseerrorका उपयोग उन अपवादों को वापस करने के लिए .NET कोड को SqlException के रूप में करने के लिए करें, जो इन त्रुटियों को एक प्रयास/पकड़ के साथ संभाल सकता है। यह दृष्टिकोण समस्याग्रस्त रिटर्न कोड जांच को प्रतिस्थापित करेगा।
क्या दूसरे बुलेट बिंदु के साथ कोई समस्या होगी जो मुझे याद आ रही है?
रिटर्न कोड के बारे में टिप्पणी के लिए उपरोक्त। वे बुरे हैं। मैं विभिन्न परियोजनाओं पर दो डेवलपर्स के साथ काम करता हूं, और एक सफलता के रूप में 1 का उपयोग करता है, दूसरा विफलता के रूप में 1 का उपयोग करता है। गन्दा गन्दा सामान। –
@ ब्रेंडन डुगन: दरअसल, इन दिनों रिटर्न कोड की आवश्यकता नहीं है, कम से कम .NET दुनिया में नहीं। अपवाद विधियों के लिए पूरी तरह से मान्य निकास पथ हैं और त्रुटियों के बारे में उपयोगी जानकारी ले जाने के लिए डिज़ाइन किए गए हैं। एक रिटर्न कोड की सबसे नज़दीकी चीज जो मुझे समझ में आती है, मुझे लगता है कि, समान रूप से संरचित या स्वत: जेनरेट की गई सेवाओं के लिए एक सामान्य रिटर्न प्रकार (सामान्य प्रकार का सामान्य 'आईरस्पॉन्स') का विचार है। इसमें 'सफलता' ध्वज और/या 'त्रुटियों' संग्रह जैसे कुछ शामिल हो सकते हैं। – David
मैं रिटर्न कोड और! = 1 के बारे में आपका बिंदु देखता हूं।मुझे लगता है कि मैंने अभी डीबी पर भरोसा नहीं किया है, इसलिए ये अतिरिक्त चेक वास्तव में अधिक हो सकते हैं। – ryanulit