2011-03-03 21 views
7

हमारे पास तीन अनुप्रयोगों में एक ऑब्जेक्ट मॉडल का उपयोग किया जा रहा है। दो कार्यक्रम डेटा एकत्र करते हैं, दूसरा इसे पढ़ता है और रिपोर्ट उत्पन्न करता है। सिस्टम बहुत डिस्कनेक्ट है, इसलिए हमारे पास एक ही डेटाबेस नहीं हो सकता है जो सभी कार्यक्रमों से बात करते हैं।क्या मुझे ओआरएम चाहिए?

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

इस मॉडल के साथ कुछ समस्याएं हैं। 1) एक्सएमएल अपशिष्ट माना जा सकता है। फाइलें बड़ी और अनावश्यक हो सकती हैं। ईमानदारी से, फ़ाइल का आकार अभी एक बड़ी चिंता नहीं है। 2) मेरी सबसे बड़ी चिंता स्मृति पैर प्रिंट है। पूरी फ़ाइल को ऑब्जेक्ट मॉडल में लोड किया जाता है, जिसे संचालित किया जाता है, फिर सहेजा जाता है।

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

मैं क्या चाहता हूं, स्मृति के बजाए फ़ाइल संग्रहण द्वारा समर्थित मेरे ऑब्जेक्ट मॉडल तक पहुंच है। मैं ऑब्जेक्ट मॉडल में परिवर्तन न्यूनतम होना चाहता हूं। जब किसी ऑब्जेक्ट को एक्सेस किया जाता है, तो यह डिस्क से आता है और जब यह सेट होता है, तो यह सहेजा जाता है (स्वचालित रूप से, यदि संभव हो तो)।

हमने एसक्यूएलसाइट, एसक्यूएल कॉम्पैक्ट 4.0 और ईएफ 4, और LINQ से एक्सएमएल (संक्षिप्त रूप से) के साथ एनएचबेर्नेट में देखा है। मैंने डिस्क में वस्तुओं को कैशिंग करने के लिए अतीत में db4o भी उपयोग किया है, लेकिन यह एक असंबंधित प्रोजेक्ट था।

इससे पहले कि मैं इनमें से किसी एक को सीखने के लिए गोता लगाने और प्रतिबद्ध करने से पहले, मैं जानना चाहता हूं कि मेरा विचार समझ में आता है या नहीं। क्या मेरे पास एक ऑब्जेक्ट मॉडल हो सकता है जो मेरे मेमोरी पदचिह्न को अनगिनत रूप से फॉलो करने के बजाय स्टोरेज माध्यम पर "जादुई रूप से" कैश करेगा? ऐसा करने के लिए सबसे छोटा रास्ता क्या है, भले ही यह सबसे सुरुचिपूर्ण न हो?

क्या ऐसी अन्य तकनीकें हैं जो मेरी मदद कर सकती हैं? मेमोरी मैप की गई फ़ाइलें, linq-to-sql, आलसी (टी) (संभवतः फ़ाइलों की आवश्यकता होने पर ऑब्जेक्ट्स लाने के लिए)।

मुझे एहसास है कि यह एक खुला अंत प्रश्न है। मैं एक बड़ी तस्वीर प्रतिक्रिया और विवरण की तलाश में हूं, अगर वहां कोई वास्तविक दुनिया अनुभव कर रहा है। लिंक सहायक होंगे ...

धन्यवाद।

+0

क्या आपके पास स्मृति संबंधी चिंताएं हैं क्योंकि आप मोबाइल उपकरणों के साथ काम करते हैं? मैं पूछता हूं क्योंकि मैं एक टैग के रूप में sql-server-ce देखता हूं। –

+0

अभी मोबाइल नहीं है, SQL सर्वर कॉम्पैक्ट को देखते हुए क्योंकि यह मेरे एप्लिकेशन (जैसे SQLite) में एम्बेड किया जा सकता है। अगर हम ईएफ के साथ जाते हैं, तो एसक्यूएल कॉम्पैक्ट डीबी बैकएंड के रूप में विचार करेगा। स्मृति चिंताओं इस तथ्य के कारण हैं कि यह 32 बिट ऐप है, इसलिए प्रक्रिया पर 2 जीबी की सीमा है। – Nate

+0

क्या आपका ऐप एक स्टैंड अकेला ऐप है? ऐसा लगता है कि आप एक केंद्रीकृत डेटाबेस नहीं चाहते हैं। ऐप mulit-user है? आप कितनी बार अद्यतन करते हैं? आवेदन के खिलाफ कितनी रिपोर्टिंग की जाती है? ये ऐसे प्रश्न हैं जो आपकी पसंद बनाने में आयातक हैं। – Andrew

उत्तर

4

मैंने एक्सएमएल फाइलों द्वारा एक्सएमएल फाइलों द्वारा समर्थित एक ही चिंता से पूरी तरह से एक ही चिंताओं से बाहर माइग्रेट करना शुरू कर दिया है। मैं भी उसी स्थिति में था जिसने कभी भी एनएचबीर्नेट का उपयोग नहीं किया था और प्रक्रिया में सीखना चाहता था। विचार समझ में आता है। आप वास्तव में केवल उन हिस्सों में लोड करने में सक्षम होंगे जिन्हें आप वास्तव में चाहते हैं (पूरे डीबी के विपरीत) और इससे भी अधिक लाभ।

अन्य चीजों के आधार पर जो आप पूछते हैं (आपके ऑब्जेक्ट मॉडल में न्यूनतम परिवर्तन, वास्तविक से ओआरएम-आधारित अनुप्रयोगों में माइग्रेट करना आसान है) मुझे यकीन नहीं है कि आप उन्हें इतनी आसानी से प्राप्त करेंगे। एनएचबीर्नेट और ईएफ 4 जैसे ओआरएम के साथ, मॉडल कक्षाएं बहुत हल्के हैं: वे मूल रूप से संपत्ति कंटेनरों से थोड़ी अधिक हैं। एक्सएमएल फाइलों के आधार पर एप्लीकेशन मॉडल में सीधे अधिक तर्क रखते हैं: वह तर्क आपको डेटा एक्सेस लेयर पर ले जाना होगा। मॉडल और डेटा एक्सेस लेयर को फिर से डिजाइन करना सबसे अधिक समय लेने वाला कार्य होगा जो आपको सामना करेगा। मुझे पता है कि यह मेरे लिए था।

एक और चीज जो मैं आपके प्रश्न से अनुमान लगाता हूं (आप कहते हैं कि आपके पास एक ही डीबी से बात करने वाले सभी तीन प्रोग्राम नहीं हो सकते हैं और आप SQLite और SQL कॉम्पैक्ट का उल्लेख करते हैं) यह है कि आप अपने डेटा को कॉपी करके अपने तीन अनुप्रयोगों में प्रतिलिपि बना रहे हैं शारीरिक रूप से फाइल करें। आप परिवर्तनों का पता कैसे लगाते हैं और आपको 3 डीबी की गठबंधन करने की आवश्यकता कैसे होती है? आप वर्तमान में परिवर्तन कैसे विलय करते हैं (यदि आपके पास 3 ऐप्स में से 2 डेटा डेटा लिख ​​सकते हैं)? डेटा को दोहराने के तरीके के आधार पर, यह कुछ ऐसा है जो ओआरएम आपकी मदद कर सकता है या नहीं।

अपनी टिप्पणी पर

  • आप एक DB में फ़ाइलों को मर्ज करने एक बिंदु पर चाहते हैं और आप पहले से ही यकीन है कि यह एक Microsoft उत्पाद हो जाएगा नहीं कर रहे हैं, तो NHibernate है आधारित संपादित कुछ अधिक अंक बेहतर चयन। लेकिन अगर आप अब LINQ का व्यापक रूप से उपयोग कर रहे हैं (आपकी टिप्पणियों में से एक के अनुसार) और एक और निर्बाध संक्रमण चाहते हैं तो मैं ईएफ 4 के लिए जाऊंगा: निबर्ननेट.लिंक वास्तव में पूर्ण नहीं है और कुछ संरचनाएं काम नहीं करती हैं।
  • दोनों एनएचबेर्नेट और ईएफ 4 बहुत दस्तावेज हैं और स्क्रैच से एक पूर्ण अनुप्रयोग बनाने के तरीके पर बहुत अच्छे ट्यूटोरियल के साथ आते हैं, इसलिए सीखने का हिस्सा वास्तव में आसान है।
  • दोनों में "मॉडल पहला" दृष्टिकोण है जहां आपको एक ऐसा उपकरण मिलता है जो आपके मॉडल कक्षाओं के आधार पर आपके लिए आपके डीबी बनाता है, इसलिए यदि आपके मॉडल वर्ग बहुत हल्के हैं तो आप उन्हें थोड़ा संशोधन के साथ उपयोग करने में सक्षम होना चाहिए।
  • जिस चीज ने मुझे कुछ समय लगाया (और अभी भी मेरे लिए काम करना मुश्किल है) एनएचबीर्नेट में कैस्केड को जिस तरह से अपेक्षित तरीके से व्यवहार करने के लिए कॉन्फ़िगर किया गया है: उदा। जब आप ऑब्जेक्ट को हटाते हैं तो "संबंधित" ऑब्जेक्ट्स का क्या होता है?
+0

उस जानकारी को साझा करने के लिए धन्यवाद। मेरा ऑब्जेक्ट मॉडल वर्तमान में बहुत हल्का है। प्रत्येक ऑब्जेक्ट केवल डेटा बाध्यकारी के लिए कुछ बदली हुई घटनाओं के साथ गुणों का एक गुच्छा है ... इसलिए शायद ईएफ या एनएचबेर्नेट उपयुक्त होगा। मैं चिंतित हूं कि सीखने की प्रक्रिया कितनी देर तक ले जाएगी। दोनों उत्पाद जटिल दिखाई देते हैं। जहां तक ​​विलय हो जाता है, मैं अब इसके बारे में बहुत चिंतित नहीं हूं। फिलहाल हम एक समय में एक फाइल पर काम कर रहे हैं। अगले वर्ष एक केंद्रीय डीबी में फ़ाइलों को मर्ज करने का प्रयास हो सकता है। हमने ऑब्जेक्ट्स को विशिष्ट रूप से फाइलों में पहचानने के प्रयास किए हैं। – Nate

+0

@Nate: टिप्पणियों में यहां जवाब देने के बजाय मैंने अपना जवाब सीधे संपादित किया (टिप्पणी के लिए बहुत लंबा ...)। आशा करता हूँ की ये काम करेगा। –

+0

अतिरिक्त जानकारी के लिए धन्यवाद एक गुच्छा। मैं एनएच और ईएफ दोनों के लिए गहरी खुदाई कर रहा हूं। मैं खुद को ईएफ के बारे में कम उत्साहित खोज रहा हूँ। सेटअप जटिल लगता है। – Nate

6

हां, ओआरएम मानचित्र एक रिलेशनशिप मॉडल के लिए एक ऑब्जेक्ट मॉडल है। वे सभी नलसाजी कामों को छिपाने का एक बहुत अच्छा काम करते हैं जो डाटाबेस को डेटा पढ़ने, लिखने, डेटा कैश करने, स्मृति को प्रबंधित करने आदि में जाने के लिए जाते हैं। वे ऑब्जेक्ट ग्राफ़ के हिस्सों को कैशिंग करने में भी सक्षम हैं और प्रदर्शन को बेहतर बनाने के लिए चीजें कर सकते हैं जैसे आलसी लोडिंग डेटा।

+0

धन्यवाद, लगता है जैसे मैं एक अच्छा रास्ता नीचे चला गया हूँ। – Nate

1

मेरा सुझाव यह है कि आप एक दस्तावेज़ डेटाबेस का उपयोग करते हैं। RavenDB आपको बहुत सारे लाभ देगा। आप ऑब्जेक्ट्स को एक रिलेशनल मॉडल में परिवर्तित किए बिना स्टोर करने में सक्षम होंगे, जैसे डीबी 4o करेगा।

हालांकि, रावेनडीबी के साथ आपके पास मानचित्र/घटा का उपयोग करके डेटा पूछने की बहुत समृद्ध संभावना है। एक अन्य लाभ यह है कि यह .NET के लिए .NET का उपयोग करके लिखा गया है, इसलिए आप लिंक में पूछताछ का आनंद लेंगे। यह विंडोज सेवा या आईआईएस में चलाया जा सकता है। यह एम्बेडेड भी चला सकता है जो परीक्षण उद्देश्यों के लिए बहुत अच्छा है। आपके डेटा एकत्र करने के अनुप्रयोगों के लिए यह एक अच्छा विचार हो सकता है।

रावेनडीबी भी प्रतिकृति का समर्थन करता है, ताकि आप एक उदाहरण में डेटा स्टोर कर सकें और इसे दूसरे पर दोहरा सकें। हो सकता है कि आपके पास वितरित सेटअप को हल कर सके।

हालांकि, आपके वितरित सेटअप की प्रकृति के आधार पर मुझे लगता है कि आप एक सेवा बस का उपयोग करना बेहतर होगा। क्या डेटा एकत्र करने वाले डेटा में आपको राज्य की आवश्यकता है? यदि नहीं, तो बस उपभोग करने के लिए सिस्टम के किसी अन्य भाग के लिए सेवा बस पर डेटा युक्त एक संदेश प्रकाशित करें। यह जटिल लग सकता है, लेकिन यह वास्तव में नहीं है। nServicebus पर एक नज़र डालें।

+0

रावेनडीबी बहुत दिलचस्प लगता है। मुझे पसंद है कि प्रारूप जेएसओएन है। मैं db4o के लाइसेंसिंग मॉडल द्वारा बंद कर दिया गया था। वे प्रति आवेदन एक अनुबंध चाहते थे और लागत अधिक थी। यह अधिक उचित लगता है। मैं इसे देख सकता हूँ। NServicebus के लिए, यह भी दिलचस्प लगता है, हो सकता है कि हम अगले वर्ष देखेंगे। अभी के लिए, स्नीकर नेट का उपयोग कर फाइलों की प्रतिलिपि बनाई गई है। मशीनें भौगोलिक दृष्टि से अलग हैं और किसी भी नेटवर्क से डिस्कनेक्ट हैं। अगले साल जब मशीनें "मातृत्व" पर वापस आती हैं तो मुझे इस्तेमाल होने के लिए कुछ प्रकार के "अपलोडर" को एक साथ रखना पड़ सकता है। – Nate

संबंधित मुद्दे