मैं सॉफ्टवेयर विकास की दुनिया के लिए अपेक्षाकृत नया हूं। मैं वर्तमान में एक परियोजना पर हूं, जो काफी बड़ा है, और यह सभ्य ओओ कोड है - ज्यादातर डोमेन संचालित डिजाइन सिद्धांतों का पालन करता है। हालांकि, अक्सर यह सिद्धांत में बहुत अच्छा लगता है, व्यावहारिक रूप से पूरे ऑब्जेक्ट रिलेशनल इम्पैडेंस बहुत खराब है, और इसका मतलब है कि सिस्टम के कुछ हिस्सों केवल ओआरएम परत का उपयोग करके काफी धीमी हैं, जब तक कि हम उन मामलों को कवर करने के लिए अनुकूलित SQL क्वेरी लिखते हैं। साथ ही, कभी-कभी हम यह देखने की कोशिश कर रहे हैं कि हमें एसक्यूएल के प्रदर्शन बनाम ओओ सिद्धांतों के आधार पर डोमेन का मॉडल करना चाहिए या नहीं।ORMs के बिना डोमेन समृद्ध अनुप्रयोग
इससे मुझे यह पूछता है - क्या इस तरह से अधिकांश एप्लिकेशन बनाए जाते हैं? मतलब - हाँ, ओओ अच्छा और अच्छा है - लेकिन मुझे यह विश्वास करना मुश्किल लगता है कि इस ऑब्जेक्ट रिलेशनल मिस्चैच से जुड़ी सभी समस्याओं के साथ, क्या यह ऐप्स बनाने का सबसे अच्छा तरीका है? वैकल्पिक दृष्टिकोण जो मैं सोच सकता हूं वह ओआरएम को कुचलना है और सिर्फ डोमेन मॉडलिंग है, और देशी एसक्यूएल प्रश्नों को सीधे हाथ से लिखना है। मैं जानना चाहता हूं कि वास्तव में पर्याप्त आकार के सॉफ्टवेयर सिस्टम इस तरह से बनाए जा रहे हैं या नहीं।
मुझे खेद है कि अगर मैं n00bish ध्वनि करता हूं - लेकिन मैं नया हूं और जानना चाहता हूं कि अन्य दृष्टिकोण क्या हैं।
+1 इस तथ्य के लिए कि सिंगल-पंक्ति ओप समान हैं, और जिस टिप्पणी को मैंने कभी नहीं सुना है, और यह सोचने लगा कि मैं एकमात्र व्यक्ति था जिसने इसे माना, कि उत्पन्न किया जा सकता है कि कोई भी कोड उत्पन्न किया जाना चाहिए। हालांकि, मैं इस बात से सहमत नहीं हूं कि ओआरएम जेनरेट कोड भी काम करता है, आम तौर पर रिलेशनल के बजाय ओओ विचारों पर मॉडलिंग से प्राप्त होने वाले ब्लेचरस टेबल डिज़ाइनों के कारण। लेकिन अभी भी "कोई भी कोड जेनरेट किया जा सकता है" कथन के लिए +1 –
+1 के लायक है। मैं शायद इसे "अच्छी तरह से" के साथ प्रत्ययित करूंगा - यानी कोड उत्पन्न न करें, _good_ कोड उत्पन्न करें। लेकिन सिद्धांत खड़ा है। – sfinnie
@ केन डाउन, यह डिजाइन के साथ एक समस्या होगी, न कि ओआरएम के साथ। लेकिन मुझे आपकी बात मिलती है, और पूरी तरह से सहमत हैं। – Ronnis