प्रत्यक्ष डेटाबेस पहुंच और सामग्री प्रदाता के बीच निर्णय कैसे लें?

Question

मैं एक ऐसे एप्लिकेशन को लिख रहा हूं जिसमें व्यावसायिक तर्क और यूआई भाग शामिल हैं। बीएल और यूआई दोनों द्वारा संग्रहीत और एक्सेस/संशोधित डेटा की काफी बड़ी मात्रा है। अधिकांश मामलों में संग्रहीत डेटा में परिवर्तन तुरंत यूआई द्वारा प्रतिबिंबित किया जाना चाहिए।

मैं कैसे तय करूं कि मुझे प्रत्यक्ष डीबी एक्सेस का उपयोग करना चाहिए या नहीं? सामग्री प्रदाता?

मैंने विषय पर कुछ पढ़ा है (1, 2) और मैं इन दो विकल्पों के बीच अंतर को समझता हूं।

इस तरह के प्रदर्शन, कोड विकास और रख-रखाव की कठिनाई स्तर, आदि के रूप समस्या के अन्य पहलुओं पर अपने विचार साझा करें

Answer 1

मेरे द्वारा लिखे गए ऐप्स में, मैंने पाया है कि एक बार जब आप सीखने की अवस्था को पार करते हैं, तो ContentProvider को लागू करना बहुत आसान है।

पेशेवरों:

• कोई बाहरी निर्भरता।
• डीबी कनेक्शन लाइफसाइक्ल ContentProvider द्वारा संभाला जाता है।
• आसानी से किसी इरादे में गतिविधियों के बीच सामग्री यूआरआई पास करें।
• CursorLoader के माध्यम से सरल पृष्ठभूमि क्वेरी (या अपना खुद का रोल)।

विपक्ष: अगर आप काम एक अच्छा उदाहरण नहीं है

• भ्रामक हो सकते हैं।
• यदि आपके पास एंटरप्राइज़ जावा पृष्ठभूमि है, तो ORM अधिक परिचित हो सकता है।

जब मैं सामग्री प्रदाता को कार्यान्वित करने का तरीका समझने की कोशिश कर रहा था, तो मैंने Google's I/O एप्लिकेशन में उदाहरण कोड डाला। निर्णय लेने से पहले, मैं कम से कम एक दिन प्रोटोटाइप खर्च करूँगा ताकि आप ट्रेडऑफ का पहला अनुभव प्राप्त कर सकें।

Answer 2

IMO: एकल APK == एक हठ परत के माध्यम से सीधी पहुँच। मल्टीपल एपीके (या तो स्वयं या दूसरों के ऐप्स को डेटा तक पहुंच प्रदान करना चाहते हैं) == सरल आवश्यकता से सामग्री प्रदाता।

Answer 3

मैं आपके ContentProvider लिखने के लिए उस अतिरिक्त समय और ऊर्जा को खर्च करने की अनुशंसा करता हूं। ContentProviders डेटा तक पहुंच साझा करने के बारे में नहीं हैं। फायदे

• आप खुद से ContentObservers
• ContentProviders के माध्यम से अपने डेटा को सुनने थ्रेड-सुरक्षित नहीं कर रहे हैं के तरीके होते हैं, लेकिन यह धागा safetly लागू करना आसान है
• कर्सर खुद को बनाए रखने के लिए कहा जा सकता है ContentProvider के notifyChange
• के माध्यम से आज तक आप अपनी व्यावसायिक परत को प्रभावित किए बिना अच्छा अमूर्त जोड़ सकते हैं। यहां एक उदाहरण दिया गया है: आप अपने एप्लिकेशन में एंड्रॉइड संपर्कों का उपयोग करते हैं। कल आप अपने स्वयं के संपर्क शुरू करने की योजना बना रहे हैं (अपनी खुद की वेब सेवा के माध्यम से)। कंटेंटप्रोवाइडर को इस आवश्यकता को बहुत ही सुंदर तरीके से आत्मसात करने के लिए संशोधित किया जा सकता है।
• जॉइन टेबल को आपके व्यवसाय-तर्क कोड को छेड़छाड़ किए बिना एक अच्छे डिज़ाइन द्वारा बहुत अच्छी तरह से उजागर किया जा सकता है। MediaStore या ContactContract जैसे कुछ Android ContentProvider देखें। उनकी CONTENT_URI परिभाषाएं देखें

सब कुछ, एक ContentProvider एक बहुत ही सुंदर एंड्रॉइड अवधारणा है जो लागू करने योग्य है। और एक बार जब आपकी परिभाषाएं हो जाएं, तो अधिक डेटा के लिए समर्थन जोड़ना बहुत मुश्किल नहीं है। यह तब एक सहायक वर्ग या आपके व्यवसाय-तर्क वर्गों में अपना डेटाबेस कोड लिखने जितना आसान होगा। https://code.google.com/p/mdsd-android-content-provider/