पुस्तकालय और आवेदन कोड के बीच अंतर?

Question

यह प्रश्न किसी वेब एप्लिकेशन से उभरा, हालांकि यह अन्य प्रकार के अनुप्रयोगों के लिए भी मान्य होना चाहिए। मैं एमवीसी का उपयोग कर रहा हूँ।

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

मुझे आश्चर्य है कि आप आमतौर पर एप्लिकेशन और लाइब्रेरी कोड (जब दोनों आंतरिक रूप से लिखे जाते हैं) के बीच रेखा खींचते हैं?

लाइब्रेरी कोड में से कुछ प्रोजेक्ट विशिष्ट हैं, लेकिन अभी भी थोड़ा सा सार है।

Answer 1

लाइब्रेरी का कोड पुन: प्रयोज्य करने का इरादा है, आमतौर पर एप्लिकेशन का कोड नहीं। कोड को लाइब्रेरी में रखें जब यह विशेष रूप से एप्लिकेशन के लिए बंधे न हों।

संदेह होने पर इस सवाल का जवाब देने की कोशिश: यदि मैं किसी अन्य अनुप्रयोग लिखने

, इस कोड रहेंगे?

Answer 2

अंगूठे का मेरा सामान्य नियम यह है: कुछ भी जो किसी अन्य प्रोजेक्ट में कभी भी उपयोग किया जा सकता है, और किसी भी एप्लिकेशन-विशिष्ट कोड पर आसानी से निर्भर नहीं किया जा सकता है (और ऐसा करने के लिए सभी प्रकार की तकनीकें हैं) में जाना चाहिए एक पुस्तकालय। तो अगर यह संभावित रूप से पुन: प्रयोज्य है तो यह पुस्तकालय में जाता है।

Answer 3

इस तरह के वर्गीकरण प्रश्नों का सामना करते समय मुझे एक बात जानना है: वर्गीकरण के परिणाम।

यह कोड "लाइब्रेरी" है, यह कोड "एप्लिकेशन" है ... जिसका लाभ इस भेद के लिए किया जा रहा है? अगर हम गलत श्रेणी में कुछ कोड डालते हैं तो क्या होगा?

एक संभावित जवाब:

यह कोड के पुन: उपयोग को प्रभावित करता है। आइए मान लें कि हमारे पास नीति है: लाइब्रेरी कोड आवश्यक हेडर आदि के साथ एक डीएलएल में उपलब्ध है। आवेदन कोड सिर्फ एक .EXE में तैनात है।

ऐप में हार्ड गणना करने के लिए एक अच्छी दिनचर्या रखें, लाइब्रेरी नहीं, तो इसे आसानी से पुन: उपयोग नहीं किया जा सकता है।

शायद आगे की चीजें सोचने की उस पंक्ति से पालन करें ... संस्करण के प्रश्न लागू होते हैं। क्या हमें बेहतर दस्तावेज तैयार करने की ज़रूरत है? [यहां तक ​​कि एक डेवलपर के साथ भी हम अधिक देखभाल कर सकते हैं?] क्या हमें कॉन्फ़िगरेशन जानकारी को बाहरी करने की ज़रूरत है, क्या मुझे दोगुना यकीन है कि कुछ भी कठिन कोड नहीं है?