एमवीवीएम में मॉडल: व्यापार वस्तु या कुछ और?

Question

मैं एमवीवीएम के साथ पकड़ने की कोशिश कर रहा हूं और इसलिए मैंने लेखों का एक समूह पढ़ा है - व्यू -> व्यू मॉडेल रिश्ते पर अधिक ध्यान केंद्रित करें और इसके बारे में सामान्य सहमति है। व्यू मॉडेल -> मॉडल रिलेशनशिप और मॉडल का गठन करने पर कम फोकस होता है और असहमति होती है। मैं उलझन में हूं और कुछ मदद चाहूंगा। उदाहरण के लिए, this article मॉडल को व्यावसायिक वस्तु के रूप में वर्णित करता है जबकि this article उस वर्ग का वर्णन करता है जो व्यवसाय वस्तुओं का प्रबंधन करता है। क्या इनमें से कोई भी सही है या यह कुछ और है?

Answer 1

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

उदाहरण के लिए - यदि आप एक GearBoxView (CockpitView में एक नियंत्रण) के साथ एक कार खेल था, CarViewModel और CarModel - सार संक्षेप का लाभ क्या CarViewModel से CarModel में है कि CarModel WorldViewModel में इस्तेमाल किया जा सकता है और कोई अन्य व्यूमोडेल। कारमोडेल में अन्य मॉडल (गियर्समोडेल, व्हीलमोडेल इत्यादि) के साथ संबंध हो सकते हैं।

आपका प्रश्न विशेष रूप से किसी व्यापार ऑब्जेक्ट के रूप में या व्यावसायिक ऑब्जेक्ट्स प्रबंधित करने के लिए मॉडल का उपयोग करने के बारे में पूछा गया: मेरा जवाब यह है कि यह दोनों कर सकता है - और दोनों के लिए ज़िम्मेदार होना चाहिए।

यहाँ एक उदाहरण है

public class WorldModel //Is a business object (aka game object) 
{ 
    private List<CarModel> _cars; 
    public List<CarModel> Cars 
    { 
     get //Here's some management of other business objects 
     { 
      //hits NetworkIO in a multiplayer game 
      if(_cars == null) 
      { 
       _cars = myExternalDataSource.GetCarsInMyGame(); 
      } 
      return _cars; 
     } 
    } 
    public Level CurrentRaceCourse { get; set; } 
    public CourseTime TimeElapsed { get; set; } 
} 

Answer 2

मुझे लगता है कि आप सही रास्ते पर हैं। "मॉडल" अस्पष्ट कई मामलों में है क्योंकि यह अन्य लोगों के लिए अलग-अलग चीजें है, और ठीक है।

मुझे के लिए, अपने व्यवसाय वस्तुओं है कि मेरे WCF सेवा से वापस आते हैं मैं अपने मॉडल पर विचार करें। इस की वजह से मेरी परियोजनाओं में नामस्थानों की पवित्र ट्रिनिटी के साथ उस सुंदर फ़ाइल संरचना नहीं है: * .Models, * .ViewModels, और *। व्यू। मैं व्यक्तिगत रूप से व्यापार तर्क या उस प्रकृति के कुछ भी "मॉडल" से वापस आने वाली वस्तुओं पर विचार करता हूं।

कुछ लोगों को एक साथ दोनों व्यापार वस्तुओं और व्यापार तर्क गांठ और फोन है कि "मॉडल" जाते हैं, लेकिन मुझे लगता है कि एक छोटे से भ्रामक क्योंकि मैं एक मॉडल चित्र मैं से एक तरह से और अधिक स्थिर होने के लिए व्यवसाय तर्क करें, लेकिन यह अर्थशास्त्र है।

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

दूसरी बात यह है कि यहां बहुत अच्छी बात यह है कि कई बार आपके पास इन प्रकार की व्यावसायिक वस्तुओं में निवेश होता है और मुझे लगता है कि बहुत से लोग "एमवीवीएम" देखते हैं और तुरंत मानते हैं कि उन्हें "एम" को परिभाषित करना शुरू करना है, भले ही उनके पास पहले से ही ठीक है।

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

Answer 3

कई अलग-अलग कार्यान्वयन और व्याख्याएं हैं।

मेरे दिमाग में, हालांकि, व्यूमोडेल का मान समन्वय से आता है।

मॉडल व्यावसायिक डेटा का प्रतिनिधि है। यह प्रक्रिया के विपरीत, स्केलर जानकारी encapsulates।

देखें स्पष्ट रूप से मॉडल की प्रस्तुति है।

व्यूमोडेल एक समन्वयक है। मेरी राय में, दृश्य मॉडल का काम दृश्य और मॉडल के बीच समन्वय करना है। इसमें व्यावसायिक तर्क नहीं होना चाहिए, बल्कि वास्तव में व्यापार सेवाओं के साथ इंटरफ़ेस होना चाहिए।

उदाहरण के लिए, यदि आप एक राय यह है कि विजेट की एक सूची है, और विजेट एक सेवा से पकड़ा जाता है, तो मैं मानना ​​चाहते हैं:

मॉडल एक List<Widget> देखें है एक ListBox ViewModel संपत्ति के लिए बाध्य है विजेट ViewModelविजेट संपत्ति उजागर करता है। इसमें IWidgetService संदर्भ भी है जो यह विजेट प्राप्त करने के लिए कॉल कर सकता है।

इस मामले में, दृश्य एक व्यावसायिक वस्तु के साथ समन्वय कर रहा है ताकि दृश्य को इसके बारे में कुछ भी पता न हो। मॉडल को मॉडल, विचार, और हर चीज के दृश्य से अनजान होना चाहिए ... उन्हें स्वतंत्र रूप से अस्तित्व में होना चाहिए कि उनका उपयोग कैसे किया जाता है। IWidgetService कि समझ में आता है ... अपने viewmodel ओवरलोड नहीं है निर्भरता इंजेक्शन कंटेनर के कुछ स्रोत का उपयोग दृश्य मॉडल करने के लिए बाध्य होगा मिलता है, या तो एकता या एक आयात MEF उपयोग करने के साथ निर्माता इंजेक्शन, आदि

आशा। इसके बारे में एक समन्वयक के रूप में सोचें जो व्यवसाय वस्तुओं और मॉडल को समझता है, लेकिन दृश्य का कोई ज्ञान नहीं है या कैसे व्यवसाय प्रक्रिया की जाती है।

Answer 4

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

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

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

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

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

Answer 5

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

व्यू मॉडल मॉडल से इकाइयों का एक मनमाना संग्रह है जो देखने की जरूरतों को पूरा करने के लिए एक साथ लाया जाता है। यदि किसी दृश्य में इनमें से 2 और उनमें से 1 की आवश्यकता होती है, तो इसका दृश्य मॉडल उन्हें मॉडल से प्रावधान करता है। आम तौर पर, मेरे पास प्रति दृश्य 1 व्यू मॉडल है।

तो एक मॉडल किराने की दुकान की तरह है। एक व्यू मॉडल एक शॉपिंग कार्ट की तरह है। और एक दृश्य एक घर की तरह है।

प्रत्येक घर में अद्वितीय आवश्यकताएं होती हैं। और प्रत्येक घर का अपना शॉपिंग कार्ट होता है जो चेरी को किराने की दुकान से घर की जरूरत होती है।

Answer 6

मेरे विचार

("मॉडल")

एक मॉडल है। बस डेटा कोई विधि नहीं है (सिवाय इसके कि प्लेटफ़ॉर्म के लिए उपयुक्त कुछ-सरल- गेटर्स/सेटर्स)।

("देखें मॉडल")

मेरे मन के लिए एक दृश्य के मॉडल के लिए तर्क है:

(1) अन्य के पीछे छिपा हुआ देखा गया तो खेतों के एक कम रैम-आवश्यकता बैकअप प्रतिलिपि उपलब्ध कराने के लिए विचार अनलोड और पुनः लोड किया जा सकता है (रैम को संरक्षित करने के लिए जब तक वे उन्हें कवर किए गए विचारों से पीछे नहीं आते)। जाहिर है यह एक सामान्य अवधारणा है जो आपके ऐप के लिए उपयोगी या उपयोगी नहीं हो सकती है।

(2) अधिक जटिल डेटा मॉडल वाले ऐप्स में, प्रत्येक संभावित डेटा परिवर्तन के फ़ील्ड से संबंधित एक कम मॉडल बनाने और बनाए रखने में आसान बनाने के बजाय, दृश्य मॉडल में सभी एप्लिकेशन फ़ील्ड को रखना कम काम है, और अक्सर प्रदर्शन के अनुसार काफी धीमी गति से नहीं।

यदि इनमें से कोई भी लागू नहीं होता है, तो मेरे दृश्य में दृश्य मॉडल का उपयोग निष्क्रिय है।

यदि मॉडल उपयुक्त हैं, तो देखने के लिए दृश्य मॉडल के एक से एक रिश्ते को देखें।

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

("देखें")

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

("मॉडल देखें" पर दोबारा गौर)

हैं (... जो के तथ्यों विचारों दिखा रहे हैं और ...) दृश्य क्षेत्रों के मूल्यों लगातार यानी होना करने के लिए जीवित रहने के एप्लिकेशन बंद/पुनः आरंभ, मॉडल मॉडल का हिस्सा है: - अन्यथा यह नहीं है।

("देखें" पर दोबारा गौर)

दृश्य सुनिश्चित करता है कि दृश्य मॉडल के रूप में (में प्रत्येक चरित्र परिवर्तन पर क्षेत्र परिवर्तनों के संदर्भ में दृश्य के रूप में उचित है, जो बहुत ही synched किया जा सकता है के साथ synch'ed है एक टेक्स्ट फ़ील्ड) या उदाहरण के लिए केवल प्रारंभिक फॉर्म आबादी पर या जब उपयोगकर्ता कुछ "जाओ" बटन पर क्लिक करता है या ऐप शटडाउन का अनुरोध करता है।

("आराम")

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

उपयोगकर्ता लेनदेन या ऐप शटडाउन ईवेंट के बाद प्रतिबद्ध होने पर: एसक्यूएल/नेटवर्कएल/फाइल/जो कुछ भी मॉडल भेजें।

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

कुछ एप्लिकेशन ईवेंट पर: ईवेंट हैंडलर दृश्य मॉडल (उपयोगकर्ता से नया डेटा) में डेटा को देखते हैं, मॉडल को आवश्यकतानुसार अपडेट करें, दृश्य बनाएं/हटाएं और मॉडल को आवश्यकतानुसार देखें, मॉडल/दृश्य मॉडल को फ्लश करें आवश्यकतानुसार (राम को बचाने के लिए)।

जब नया दृश्य दिखाना चाहिए: व्यूमोडेल बनने के बाद मॉडल से प्रत्येक व्यूमोडेल को पॉप्युलेट करें। फिर मॉडल देखने के लिए संलग्न दृश्य बनाएं।

(संबंधित मुद्दा: यदि कोई डेटा प्रदर्शन (संपादन नहीं) के लिए मुख्य रूप से सेट नहीं पूरी तरह से रैम में लोड किया जाना चाहिए क्या?)

वस्तुओं के सेट के लिए है कि पूरी तरह से राम के राम कारण में आयोजित नहीं किया जाना चाहिए विचारों का उपयोग करें, वस्तुओं की समग्र गणना पर जानकारी तक पहुंचने के लिए एक सार इंटरफ़ेस बनाएं और एक समय में वस्तुओं को एक्सेस करने के लिए भी।

इंटरफ़ेस और इसके "इंटरफ़ेस उपभोक्ता" को ऑब्जेक्ट प्रदान करने वाले एपीआई स्रोत के आधार पर अज्ञात/अनुमानित और/या बदलते ऑब्जेक्ट्स की संख्या से निपटना पड़ सकता है। यह इंटरफ़ेस मॉडल और दृश्य मॉडल के लिए समान हो सकता है।

(संबंधित मुद्दा: क्या हुआ अगर किसी भी डेटा मुख्य रूप से संपादन के लिए सेट करते हैं, रैम में लोड किया जाना चाहिए)

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

(MVVM की वैचारिक महत्व?)

स्वच्छ मंच-नास्तिक तरह से अनुमति देते हैं और भ्रष्ट मॉडल के बिना विचारों में डेटा परिवर्तन खो करने के लिए; और मॉडल के माध्यम से केवल मान्य डेटा को अनुमति देने के लिए जो डेटा के "मास्टर" sanitized संस्करण के रूप में बनी हुई है।

क्यों उस दृश्य मॉडल से बहती है मॉडल करने के लिए समझने के लिए महत्वपूर्ण मॉडल से विपरीत दिशा में बहती मॉडल देखने पर जबकि नहीं हैं उपयोगकर्ता इनपुट के डेटा सत्यापन पर सशर्त है।

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

---

अपने मूल प्रश्न के उत्तर में, यह मॉडल में खेतों की अद्यतन पर सत्यापन नियमों के अंतर्संबंधों की डिग्री के एक सवाल है।

मॉडल फ्लैट हैं, जहां वे एक-से-एक रिश्ते के लिए या सरणियों या एक-से-कई संबंधों के लिए अन्य कंटेनर वस्तुओं के माध्यम से हो सकता है लेकिन submodels के संदर्भ के साथ, सीधे।

यदि सत्यापन नियमों की जटिलता ऐसी है कि केवल एक सफल उपयोगकर्ता फ़ॉर्म को भरने या फ़ील्ड नियमित रूप से अभिव्यक्तियों और संख्यात्मक श्रेणियों की सूची के विरुद्ध आने वाले संदेश को सत्यापित करना (और प्रासंगिक संदर्भ वस्तुओं की कैश या विशेष रूप से प्राप्त प्रतिलिपि के खिलाफ किसी ऑब्जेक्ट की जांच करना और/या कुंजी) गारंटी नहीं है कि व्यापार की वस्तुओं के लिए अद्यतन 'ईमानदारी के साथ' हो जाएगा के लिए पर्याप्त है, और नियमों को ईवेंट हैंडलर के हिस्से के रूप आवेदन के द्वारा जांच की जाती है, तो मॉडल सिर्फ सरल getters और setters हो सकता है।

आवेदन कर सकते हैं शायद (सर्वोत्तम) ऐसा करते हैं सीधे इन-लाइन ईवेंट हैंडलर्स जहां नियमों की संख्या बहुत आसान है में।

कुछ मामलों में मॉडल पर सेटर्स में इन सरल नियमों को रखने के लिए बेहतर हो सकता है लेकिन यह सत्यापन ओवरहेड तब डेटाबेस लोड पर किया जाता है जब तक कि आपके पास वैध किए बिना सेटिंग के लिए अतिरिक्त कार्य नहीं होते हैं। तो सरल डेटा मॉडल के लिए मैं इन अतिरिक्त सेटर्स को लिखने से बचने के लिए एप्लिकेशन इवेंट हैंडलर में सत्यापन रखना चाहता हूं।

लेकिन अगर नियमों को और अधिक जटिल हैं या तो:

(क) एक एकल विधि एक विशेष वस्तु वास्तव में असंख्य क्षेत्र में परिवर्तन के लिए डेटा वाली सामान्य व्यापार वस्तुओं की एक समग्र प्रत्येक जटिल मॉडल बदलाव के लिए लिखा है कि ले जा , और नियम नियमों के सत्यापन के आधार पर सफल या असफल हो सकता है - मुखौटा पैटर्न;

या

(ख) एक "सूखी रन"/परिकल्पना/"परीक्षण" मॉडल या मॉडल की उप-समूह की प्रतिलिपि पहले बनाया जाता है, एक समय में एक संपत्ति की स्थापना, और फिर एक सत्यापन दिनचर्या रन प्रतिलिपि पर। यदि सत्यापन सफल होता है, परिवर्तन मुख्य मॉडल अन्यथा डेटा त्याग दिया जाता है में आत्मसात कर रहे हैं और एक त्रुटि उठाया।

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

मॉडल (संभवतः) सरल गेटर्स/सेटर्स के साथ फ़ील्ड के गुच्छा की तुलना में मॉडल अधिक जटिल हो रहा है, यदि आप कक्षाओं के गेटर्स/सेटर्स (ओ 2 आर मैपर टूल के साथ) को "बढ़ाना" शुरू करते हैं, या अतिरिक्त जोड़ना चाहते हैं ट्रांजैक्शन मॉनीटरिंग एपीआई, सुरक्षा एपीआई (लॉगिंग आदि के लिए अनुमतियों की जांच करने के लिए), अकाउंटिंग एपीआई, ऐसे तरीके जो पहलू या सेट के लिए आवश्यक किसी भी संबंधित डेटा को पूर्व-प्राप्त करते हैं, या जो कुछ भी मिलता है या सेट पर होता है। इस क्षेत्र पर एक प्रदर्शनी के लिए "पहलू उन्मुख प्रोग्रामिंग" देखें।