Android के विकास के लिए डिजाइन पैटर्न। भाग 4 - डेटा की बचत। डोमेन मॉडल, रिपॉजिटरी, सिंगलटन और बीडीडी

मैं तुरंत कहना चाहता हूं कि लेख में मैं यह नहीं बताऊंगा कि डेटा प्रदाता के साथ कैसे काम करना है। यह दस्तावेज़ीकरण और इंटरनेट पर कई लेखों में पाया जा सकता है।
यहां मैं डोमेन मॉडल, सिंगलटन, रिपोजिटरी डिजाइन पैटर्न, व्यवहार प्रेरित विकास (बीडीडी) दृष्टिकोण के बारे में बात करूंगा और मैंने उन्हें अपने कार्यक्रम में कैसे इस्तेमाल किया।

डोमेन मॉडल टेम्पलेट का उपयोग उन मामलों में किया जाता है जब विकास विषय क्षेत्र से किया जाता है, ऐसे मामलों में एक स्पष्ट विषय क्षेत्र होता है और इसकी शर्तें बस बाइट्स में सन्निहित हैं।

उदाहरण के लिए, मेरे कार्यक्रम में, विषय क्षेत्र में कई अलार्म के रूप में निर्धारित डेटा होता है, अलार्म के लिए आप सप्ताह और समय के दिनों को सेट कर सकते हैं, साथ ही साथ "अलार्म चालू है"। उदाहरण के लिए, एक अलार्म प्राप्त करने के लिए कई एल्गोरिदम भी हैं जो अगले काम करेंगे और इसे चालू करने की तारीख और समय। चूंकि अलार्म घड़ी डोज़ कर सकती है, इसलिए यह पता चलता है कि एक अलार्म में विभिन्न कार्यों के साथ कई अलार्म हैं: पहला अलार्म, डोज़ और अंतिम डोज़ जब डोज़ बटन उपलब्ध नहीं है। इसलिए, निकटतम निरपेक्ष समय और कार्रवाई को सिखाने के लिए एक एल्गोरिथ्म भी है।
नई अलार्म घड़ी बनाने और मौजूदा को हटाने / संपादित करने के लिए एल्गोरिदम भी हैं।

यही है, मेरे विषय क्षेत्र में कई अलार्म और कई एल्गोरिदम के रूप में डेटा है जो विषय क्षेत्र के तर्क को लागू करते हैं।

मैंने इस डिज़ाइन पैटर्न का उपयोग करने का निर्णय क्यों लिया। वैकल्पिक रूप से, मैं एक अलग वर्ग बना सकता था जो अलार्म बनाता / संपादित करता है और उन्हें डेटाबेस में सहेजता है, और निकटतम अलार्म की गणना के लिए एल्गोरिदम को अन्य कक्षा में बनाया जा सकता है।

सबसे पहले, विषय क्षेत्र के संदर्भ में, हम अलार्म की एक सूची के साथ काम करते हैं, इसमें नए अलार्म जोड़ते हैं और उससे पूछते हैं कि कौन सी अलार्म घड़ी अगले है। अर्थात्, यह डेटा और एल्गोरिदम को एन्कैप्सुलेट करने के मामले में सुविधाजनक लगता है। इस तरह के एक मॉडल मानव धारणा के लिए अधिक सुविधाजनक है।

दूसरे, इस मामले में, जब मैं मॉडल का परीक्षण करता हूं, तो मैं सामान्य उपयोगकर्ता व्यवहार का परीक्षण कर सकता हूं। उदाहरण के लिए, एक अलार्म बनाएं, इसके लिए एक समय निर्धारित करें, जांचें कि मॉडल अगली बार सही देता है, फिर मैं एक नया अलार्म जोड़ता हूं, और मैं पुराने को बंद कर देता हूं और जांचता हूं कि इस बार अगली बार सही है।

इस दृष्टिकोण को व्यवहार प्रेरित विकास कहा जाता है। इसका लाभ यह है कि मैं विषय क्षेत्र के संदर्भ में मॉडल का परीक्षण कर सकता हूं, अर्थात इकाई परीक्षणों में मैं उपयोगकर्ता के सामान्य व्यवहार की नकल करता हूं। इस तथ्य के कारण कि यह इकाई परीक्षण तंत्र के माध्यम से कार्यान्वित किया जाता है, प्रत्येक रिलीज से पहले मैं इन परीक्षणों को चला सकता हूं और यह सुनिश्चित कर सकता हूं कि मेरा प्रोग्राम प्रोग्राम आम तौर पर मूल उपयोगकर्ता कार्यों को पूरा करता है।

अगर मैंने अलार्म को संपादित करने / सहेजने के लिए एक अलग वर्ग और निकटतम अलार्म की गणना के लिए एक अलग वर्ग का उपयोग किया है, तो मैं निश्चित रूप से उन्हें अलग से परीक्षण करूंगा, लेकिन मैं उन्हें एक साथ नहीं देख सकता था और मैं उपयोगकर्ता की बुनियादी क्रियाओं की जांच नहीं कर सकता था।

मॉडल और उसके इंटरफेस

विषय क्षेत्र को लागू करते समय, मैंने अलार्मलिस्टमॉडल वर्ग के रूप में एक मॉडल लागू किया, जो अलार्म को संग्रहीत करता है और इन एल्गोरिदम को लागू करता है। मैं इस बात पर जोर देना चाहता हूं कि मॉडल को डेटाबेस को बचाने के बारे में कुछ भी नहीं पता है। मॉडल को सहेजना रिपॉजिटरी द्वारा किया जाता है, जिसके बारे में मैं नीचे चर्चा करूंगा।

मॉडल में अलार्म की एक सूची है, जिसका उपयोग अगले अलार्म की गणना करते समय या संपादन करते समय किया जाता है। यही है, मॉडल डेटा संग्रहीत करता है और एल्गोरिदम को लागू करता है। जाहिर है, इन एल्गोरिदम को अलार्म क्लास में लागू नहीं किया जा सकता है, क्योंकि अगली बार गणना करने वाले को सभी शामिल अलार्म के बारे में पता होना चाहिए, और अलार्म ऑब्जेक्ट केवल अपने बारे में जानता है। इसलिए, मेरी अलार्म घड़ी डेटा के साथ और किसी भी एल्गोरिदम के बिना एक सरल संरचना है।

मॉडल दो इंटरफेस को लागू करता है।
IAlarmListModel - विषय क्षेत्र से संबंधित विधियों को लागू करता है, उदाहरण के लिए, एक नई अलार्म घड़ी बनाएं और अगले ऑपरेशन के समय का पता लगाएं।
IListModelData - वह इंटरफ़ेस जो डेटाबेस में मॉडल को बचाने के लिए रिपॉजिटरी द्वारा उपयोग किया जाता है या इसके विपरीत डेटाबेस से पढ़ा जाता है।

मैं यह नोट करना चाहता हूं कि भंडार पूरी तरह से मुझ से सभी डेटा को पढ़ता है, डेटाबेस से सभी अलार्म का शेड्यूल पढ़ता है। यह इस तथ्य के कारण है कि प्रत्येक के लिए डेटाबेस में चढ़ने के लिए इतने सारे अलार्म नहीं हैं, और यह भी क्योंकि मुझे अगले अलार्म की गणना करने के लिए सभी शामिल अलार्म की आवश्यकता है, और सूची में प्रदर्शित करने के लिए मुझे सभी अलार्मों की आवश्यकता है।

नीचे मॉडल और इंटरफेस के मुख्य स्रोत हैं:

public interface IAlarmListModel { IDisplayAlarm getNextDisplayAlarm(Date curTime); IDisplayAlarm createAlarm(); void updateAlarm(IDisplayAlarm iDisplayAlarm); void addAlarm(IDisplayAlarm iDisplayAlarm); void deleteAlarm(IDisplayAlarm item); void takeAlarmForEdit(int alarmID); IDisplayAlarm getEditingAlarm(); void saveEditingAlarm(boolean stayEditing); } 

TakeAlarmForEdit () और saveEditingAlarm () विधियों को संपादन के लिए अलार्म को क्लोन करने और उपयोगकर्ता द्वारा किए गए परिवर्तनों को त्यागने में सक्षम होने के लिए आवश्यक है यदि वह "रद्द करें" पर क्लिक करें। ये तरीके डेटाबेस के लिए कुछ भी नहीं बचाते हैं, केवल अलार्म की आंतरिक सूची के लिए।

 public interface IListModelData<T> { ArrayList<T> getItemList(); ArrayList<T> getDeletedItemList(); } 

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

 public class AlarmListModel implements IAlarmListModel, IListModelData<AlarmItem> { private ArrayList<AlarmItem> alarmArray = new ArrayList<AlarmItem>(); private ArrayList<AlarmItem> alarmArrayDeleted = new ArrayList<AlarmItem>(); @Override public synchronized IDisplayAlarm getNextDisplayAlarm(Date curTime) { // ,      . } @Override public synchronized AlarmItem createAlarm() { AlarmItem alarm = new AlarmItem(); alarm.setId(0); //  ,      , //  ID     alarm.setState(EntityState.ADDED); alarm.setName("New alarm");// alarm.setIssue(8, 0, false);//8    alarm.setEnable(true);//  //    // false ,      alarm.setDay(Calendar.MONDAY, true, false); alarm.setDay(Calendar.TUESDAY, true, false); alarm.setDay(Calendar.WEDNESDAY,true, false); alarm.setDay(Calendar.THURSDAY, true, false); alarm.setDay(Calendar.FRIDAY, true, false); alarm.setDay(Calendar.SATURDAY, false, false); alarm.setDay(Calendar.SUNDAY, false, false); return alarm; } @Override public synchronized void addAlarm(IDisplayAlarm item) { AlarmItem alarm = (AlarmItem)item; if(item.getId() > 0) { ex = new Exception("    "); } alarm.setState(EntityState.ADDED); alarmArray.add(alarm); } @Override public synchronized void updateAlarm(IDisplayAlarm item) { AlarmItem alarm = (AlarmItem)item; alarmArray.set(getPositionByID(item.getId()), alarm); } @Override public synchronized void deleteAlarm(IDisplayAlarm item) { AlarmItem alarm = (AlarmItem)item; alarmArray.remove(alarm); alarm.setState(EntityState.DELETED); alarmArrayDeleted.add(alarm); } public synchronized void takeAlarmForEdit(int alarmID) { if(alarmID > 0) editAlarm = ((AlarmItem)getDisplayAlarmByID(alarmID)).clone(); else editAlarm = createAlarm(); } @Override public synchronized AlarmItem getEditingAlarm() { return editAlarm; } @Override public synchronized void saveEditingAlarm(boolean stayEditing) { if(editAlarm == null)return; if(editAlarm.getId() > 0) updateAlarm(editAlarm); else addAlarm(editAlarm); if(!stayEditing)editAlarm = null; } @Override public synchronized ArrayList<AlarmItem> getItemList() { return alarmArray; } @Override public synchronized ArrayList<AlarmItem> getDeletedItemList() { return alarmArrayDeleted; } } 

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

CreateAlarm () विधि, आपको अलार्म घड़ी के कारखाने के लिए मॉडल की आवश्यकता है। मैं यह नोट करना चाहता हूं कि फैक्ट्री निर्मित वस्तु को अलार्म की आंतरिक सूची में नहीं जोड़ती है, इसके लिए एक ऐडआर्म (विधि) है

AddAlarm (), updateAlarm (), deleteAlarm () विधियों को अलार्म की आंतरिक सूची के साथ काम करने की आवश्यकता है। जैसा कि आप पहले ही देख चुके हैं, अलार्म आईटम वर्ग में राज्य की निगरानी के लिए तरीके हैं; ये राज्य डेटाबेस के सापेक्ष रिकॉर्ड की स्थिति दिखाते हैं:

 public enum EntityState { ADDED, NOT_CHANGED, CHANGED, DELETED } 

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

मैं यह नोट करना चाहता हूं कि AddAlarm विधि में मैं एक चाल का उपयोग करता हूं। यदि मेरे पास कोई अपवाद है जब गलत अलार्म घड़ी को संग्रह में जोड़ा जाता है, तो मैं एक अपवाद नहीं फेंकता, लेकिन चुपचाप इस अपवाद को क्षेत्र में सहेजें:

 ex = new Exception("    "); 

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

अलार्म घड़ी के एडिट फॉर्म के लिए मुख्य रूप से takeAlarmForEdit (), getEditingAlarm (), saveEditingAlarm () की आवश्यकता होती है। जैसा कि मैंने कहा, वे अलार्म को क्लोन करने के लिए आवश्यक हैं, इसे बदल दें और यदि आवश्यक हो, तो परिवर्तनों को छोड़ दें।

भंडार से मिलो

मॉडल को बचाने और पढ़ने के लिए रिपॉजिटरी के केवल दो तरीके हैं:

 public interface IAlarmRepository { public abstract void load(); public abstract void save(); } 

जैसा कि आप देख सकते हैं, मॉडल का कोई उल्लेख नहीं है। मेरे मॉडल को सिंगलटन टेम्प्लेट के रूप में लागू किया गया है, अर्थात पूरे कार्यक्रम में मॉडल का केवल एक उदाहरण है और यदि प्रोग्राम का एक हिस्सा, उदाहरण के लिए, UI, मॉडल में कुछ बदलता है, तो दूसरा भाग, उदाहरण के लिए, एक सर्वर या रिपॉजिटरी, उसी उदाहरण से डेटा पढ़ना मॉडल तुरंत नवीनतम परिवर्तन प्राप्त करेंगे। यह बहुत सुविधाजनक है जब आपको आवेदन के हिस्सों के बीच एकमात्र मौजूदा वस्तु को स्थानांतरित करने की आवश्यकता होती है।

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

इसलिए मैंने स्थैतिक वर्ग के साथ समस्या को हल किया इस तथ्य के कारण कि मैं रोबोग्यूइस का उपयोग करता हूं, जो इस मामले में मॉडल का कारखाना है। RoboGuice का उपयोग करने से हमें यह दिखाने की अनुमति मिलती है कि वर्ग सिंगलटन का उपयोग करता है और RoboGuice के माध्यम से मैं सिंग्लटन को परीक्षणों में अनुकरण के साथ बदल सकता हूं।

सही राज्य की समस्या को इस तथ्य से हल किया जाता है कि मॉडल के साथ सभी परिवर्तन एक कॉल में विधि के लिए किए जाते हैं और सभी विधियों को सिंक्रनाइज़ के रूप में चिह्नित किया जाता है, ताकि एक ही समय में मॉडल पर दो कॉल न हों।

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

तो सीखें कि सिंगलटन को ठीक से कैसे पकाना है।

यहाँ रिपॉजिटरी कोड है:

 public class AlarmRepository implements IAlarmRepository { // Singleton . //,   Singleton   RoboGuice @Inject private IAlarmListModel alarmListModel; @Inject Context context; @Inject public AlarmRepository() { db = (new DBHelper(context)).getWritableDatabase(); } @Override public synchronized void load() { IListModelData<AlarmItem> res = (IListModelData<AlarmItem>)alarmListModel; res.getItemList().clear(); res.getDeletedItemList().clear(); Cursor c = db.query(DBHelper.TABLE_NAME, projection, null, null, null, null, DBHelper.A_ID); c.moveToNext(); AlarmItem alarm = null; while(!c.isAfterLast()) { alarm = cvToAlarm(c); res.getItemList().add(alarm); c.moveToNext(); } c.close(); alarmListModel.setLoaded(true); } @Override public synchronized void save() { IListModelData<AlarmItem> model = (IListModelData<AlarmItem>)alarmListModel; ContentValues v = null; for(AlarmItem item : model.getItemList()) { switch(item.getState()) { case CHANGED: v = alarmToCV(item); int retVal = db.update(DBHelper.TABLE_NAME, v, DBHelper.A_ID + "=" + item.getId(), null); break; case ADDED: v = alarmToCV(item); int id = (int)db.insert(DBHelper.TABLE_NAME, null, v); item.setId(id); break; case DELETED: ex = new Exception("      DELETED   "); break; } item.setState(EntityState.NOT_CHANGED); } for(AlarmItem item : model.getDeletedItemList()) switch(item.getState()) { case CHANGED: ex = new Exception("      CHANGED   "); break; case ADDED: ex = new Exception("      ADDED   "); break; case DELETED: int retVal = db.delete(DBHelper.TABLE_NAME, DBHelper.A_ID + "=" + item.getId(), null); break; } model.getDeletedItemList().clear(); } } 

मैंने तरीकों cvToAlarm () और AlarmToCV () को उनमें बहुत सी लाइनें नहीं दिखाईं, जिनमें अलार्म फ़ील्ड्स की डेटाबेस टेबल और इसके विपरीत फ़ील्ड्स की मैपिंग की गई थी, जिसे मैं आर्टिकल से जोड़ना नहीं चाहता।

एक बार फिर मैं कहूंगा कि मैं यह नहीं मानूंगा कि यहां कॉन्टेन प्रदाताओं के साथ कैसे काम किया जाए। इसलिए, सभी प्रकार के db.update () और db.insert () का क्या मतलब है, एसडीके देखें।

यहां मैं रिपॉजिटरी डिजाइन पैटर्न के बारे में बात करूंगा। जैसा कि आप सिंक्रनाइज़ किए गए तरीकों की घोषणा के रूप में माध्यमिक सुविधाओं से समझते हैं, मेरी रिपॉजिटरी भी सिंगलटन है।

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

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

पुनश्च
चूंकि लेख इतना बड़ा निकला, इसलिए मैंने मॉडल और रिपॉजिटरी के लिए परीक्षण दिखाना शुरू नहीं किया। प्रस्तुतकर्ता के परीक्षण की तुलना में मौलिक रूप से नया कुछ भी नहीं है। हम परीक्षण में परीक्षण किए गए वर्ग का एक उदाहरण भी बनाते हैं, रोबोगुइस के माध्यम से सिमुलेशन के साथ निर्भरता को प्रतिस्थापित करते हैं, और परिणामस्वरूप शव परीक्षण करते हैं।

अन्य लेखों में पढ़ें

- परिचय
- एमवीपी और यूनिट परीक्षण। जेडी वे
- यूजर इंटरफेस, परीक्षण, AndroidMock
- डेटा की बचत। डोमेन मॉडल, रिपॉजिटरी, सिंगलटन और बीडीडी
- सर्वर साइड, रोबूगाइस, परीक्षण का कार्यान्वयन
- छोटे कार्य, सेटिंग्स, लॉगिंग, ProGuard