ORM के साथ डेटा लाना आसान है! या नहीं?

परिचय

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

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

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

डेटा का नमूना: आलसी या नहीं?

यदि आपके डेटा मॉडल में केवल एक इकाई है, तो आप ORM के साथ काम करते समय किसी भी समस्या पर ध्यान नहीं देंगे। एक छोटा सा उदाहरण देखते हैं। मान लीजिए हमारे पास एक User () इकाई है जिसमें दो विशेषताएँ हैं: ID और Name () :

 public class User { @Id @GeneratedValue private int id; private String name; //Getters and Setters here } 

डेटाबेस से इस इकाई का एक उदाहरण प्राप्त करने के लिए, हमें सिर्फ EntityManager ऑब्जेक्ट की एक विधि को कॉल करने की आवश्यकता है:

 EntityManager em = entityManagerFactory.createEntityManager(); User user = em.find(User.class, id); 

जब एक-से-कई संबंध प्रकट होते हैं तो चीजें थोड़ी दिलचस्प हो जाती हैं:

 public class User { @Id @GeneratedValue private int id; private String name; @OneToMany private List<Address> addresses; //Getters and Setters here } 

यदि हमें डेटाबेस से उपयोगकर्ता का उदाहरण निकालने की आवश्यकता है, तो सवाल उठता है: "क्या हम पते भी चुनते हैं?"। और यहाँ "सही" उत्तर है: "निर्भर करता है ..." कुछ मामलों में हमें पते की आवश्यकता होगी, कुछ में - नहीं। आमतौर पर, ओआरएम निर्भर रिकॉर्ड लाने के दो तरीके प्रदान करता है: आलसी और लालची। डिफ़ॉल्ट रूप से, अधिकांश ORM आलसी तरीके का उपयोग करते हैं। लेकिन, अगर हम यह कोड लिखते हैं:

 EntityManager em = entityManagerFactory.createEntityManager(); User user = em.find(User.class, 1); em.close(); System.out.println(user.getAddresses().get(0)); 

... तो हमें “LazyInitException” अपवाद मिलता है, जो बहुत नए लोगों को भ्रमित करता है जिन्होंने ओआरएम के साथ काम करना शुरू कर दिया है। और यहां वह क्षण आता है जब आपको एक इकाई के "संलग्न" और "अलग किए गए" उदाहरणों के बारे में एक कहानी शुरू करने की आवश्यकता होती है, सत्र और लेनदेन क्या हैं।
हां, इसका मतलब है कि सत्र के लिए इकाई को "संलग्न" होना चाहिए ताकि आप निर्भर डेटा का चयन कर सकें। ठीक है, चलो अभी लेनदेन को बंद नहीं करते हैं, और जीवन तुरंत आसान हो जाएगा। और यहां एक और समस्या पैदा होती है - लेन-देन लंबा हो जाता है, जिससे गतिरोध का खतरा बढ़ जाता है। लेनदेन कम करें? यह संभव है, लेकिन अगर आप कई, कई छोटे लेन-देन करते हैं, तो हमें "टेल ऑफ़ कोमार कोमारोविच - एक लंबी नाक और एक प्यारे मिशा - एक छोटी पूंछ" मिलती है, जिसके बारे में कि छोटे भालू मच्छरों की भीड़ कैसे जीती है - यह डेटाबेस के साथ होगा। यदि छोटे लेनदेन की संख्या में काफी वृद्धि होती है, तो प्रदर्शन की समस्याएं उत्पन्न होंगी।
जैसा कि कहा गया था, जब उपयोगकर्ता के बारे में डेटा लाते हैं, तो पते की आवश्यकता हो सकती है या नहीं, इसलिए, व्यापार तर्क के आधार पर, आपको संग्रह का चयन करने की आवश्यकता है या नहीं। कोड में नई शर्तों को जोड़ना आवश्यक है ... हम्म् ... कुछ किसी तरह जटिल हो रहा है।

तो, क्या होगा अगर आप एक अलग प्रकार के नमूने की कोशिश करते हैं?

 public class User { @Id @GeneratedValue private int id; private String name; @OneToMany(fetch = FetchType.EAGER) private List<Address> addresses; //Getters and Setters here } 

खैर ... आप यह नहीं कह सकते कि इससे बहुत मदद मिलेगी। हां, हम घृणित LazyInit से छुटकारा पा लेंगे और यह जांचने की कोई आवश्यकता नहीं है कि इकाई सत्र से जुड़ी है या नहीं। लेकिन अब हमारे पास प्रदर्शन की समस्याएं हो सकती हैं, क्योंकि हमें हमेशा पते की आवश्यकता नहीं होती है, लेकिन हम सर्वर की मेमोरी में इन वस्तुओं का चयन करते हैं।
कोई और विचार?

स्प्रिंग जेडीबीसी

कुछ डेवलपर्स ओआरएम से इतने थक गए हैं कि वे वैकल्पिक रूपरेखाओं पर स्विच करते हैं। उदाहरण के लिए, स्प्रिंग जेडीबीसी पर, जो रिलेशनल डेटा को ऑब्जेक्ट डेटा को "सेमी-ऑटोमैटिक" मोड में बदलने की क्षमता प्रदान करता है। डेवलपर प्रत्येक मामले के लिए क्वेरीज़ लिखता है, जहाँ विशेषताओं के एक विशेष सेट की आवश्यकता होती है (या समान कोड उन मामलों के लिए पुन: उपयोग किया जाता है जहाँ समान डेटा संरचनाओं की आवश्यकता होती है)।

इससे हमें काफी लचीलापन मिलता है। उदाहरण के लिए, आप संबंधित निकाय ऑब्जेक्ट बनाए बिना केवल एक विशेषता का चयन कर सकते हैं:

 String name = this.jdbcTemplate.queryForObject( "select name from t_user where id = ?", new Object[]{1L}, String.class); 

या सामान्य रूप में एक वस्तु का चयन करें:

 User user = this.jdbcTemplate.queryForObject( "select id, name from t_user where id = ?", new Object[]{1L}, new RowMapper<User>() { public User mapRow(ResultSet rs, int rowNum) throws SQLException { User user = new User(); user.setName(rs.getString("name")); user.setId(rs.getInt("id")); return user; } }); 

आप उपयोगकर्ता के लिए पतों की एक सूची भी चुन सकते हैं, आपको केवल n + 1 प्रश्नों की समस्या से बचने के लिए थोड़ा और कोड लिखना होगा और SQL क्वेरी की सही ढंग से रचना करनी होगी।

सू, फिर से जटिल। हां, हम सभी प्रश्नों को नियंत्रित करते हैं और डेटा को ऑब्जेक्ट्स पर मैप कैसे किया जाता है, लेकिन हमें अधिक कोड लिखने, SQL सीखने और यह जानने की आवश्यकता है कि डेटाबेस में प्रश्नों का निष्पादन कैसे किया जाता है। व्यक्तिगत रूप से, मुझे लगता है कि एसक्यूएल का ज्ञान एक एप्लिकेशन प्रोग्रामर के लिए एक आवश्यक कौशल है, लेकिन हर कोई इस तरह से नहीं सोचता है, और मैं पोलेमिक्स में संलग्न नहीं होने जा रहा हूं। आखिरकार, इन दिनों x86 विधानसभा निर्देशों का ज्ञान भी वैकल्पिक है। आइए बेहतर तरीके से सोचते हैं कि प्रोग्रामर के लिए जीवन को आसान कैसे बनाया जाए।

JPA EntityGraph

और चलो एक कदम पीछे हटो और सोचो, हमें क्या चाहिए? ऐसा लगता है कि हमें केवल यह इंगित करने की आवश्यकता है कि प्रत्येक मामले में हमें किन विशेषताओं की आवश्यकता है। अच्छा, चलो करते हैं! जेपीए 2.1 ने एक नया एपीआई - एंटिटीग्राफ (इकाई ग्राफ) पेश किया। विचार बहुत सरल है: हम डेटाबेस से क्या चुनेंगे, इसका वर्णन करने के लिए हम एनोटेशन का उपयोग करते हैं। यहाँ एक उदाहरण है:

 @Entity @NamedEntityGraphs({ @NamedEntityGraph(name = "user-only-entity-graph"), @NamedEntityGraph(name = "user-addresses-entity-graph", attributeNodes = {@NamedAttributeNode("addresses")}) }) public class User { @Id @GeneratedValue private int id; private String name; @OneToMany(fetch = FetchType.LAZY) private Set<Address> addresses; //Getters and Setters here } 

इस इकाई के लिए दो रेखांकन वर्णित हैं: user-only-entity-graph Addresses विशेषता (आलसी लेबल) का चयन नहीं करता है, जबकि दूसरा ग्राफ ORM को इस विशेषता का चयन करने के लिए कहता है। यदि हम Addresses को उत्सुक के रूप में चिह्नित करते हैं, तो ग्राफ को नजरअंदाज कर दिया जाएगा और पते वैसे भी चुने जाएंगे।

तो, JPA 2.1 में, आप इस तरह से डेटा का नमूना ले सकते हैं:

 EntityManager em = entityManagerFactory.createEntityManager(); EntityGraph graph = em.getEntityGraph("user-addresses-entity-graph"); Map<String, Object> properties = Map.of("javax.persistence.fetchgraph", graph); User user = em.find(User.class, 1, properties); em.close(); 

यह दृष्टिकोण काम को बहुत सरल करता है, आलसी विशेषताओं और लेनदेन की लंबाई के बारे में अलग से सोचने की आवश्यकता नहीं है। एक अतिरिक्त बोनस यह है कि ग्राफ SQL क्वेरी के स्तर पर लागू होता है, इसलिए जावा एप्लिकेशन में "अतिरिक्त" डेटा का चयन नहीं किया जाता है। लेकिन एक छोटी सी समस्या है: आप यह नहीं कह सकते हैं कि कौन से गुण चुने गए थे और कौन से नहीं थे। जाँच के लिए एक एपीआई है, यह PersistenceUtil वर्ग का उपयोग करके किया जाता है:

 PersistenceUtil pu = entityManagerFactory.getPersistenceUnitUtil(); System.out.println("User.addresses loaded: " + pu.isLoaded(user, "addresses")); 

लेकिन यह बहुत नीरस है और हर कोई इस तरह की जांच करने के लिए तैयार नहीं है। क्या कुछ और है जिसे आप सरल बना सकते हैं और सिर्फ उन विशेषताओं को नहीं दिखा सकते हैं जिन्हें चुना नहीं गया था?

वसंत अनुमान

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

 interface NamesOnly { String getName(); } 

अब आप उपयोगकर्ता संस्थाओं को लाने के लिए स्प्रिंग जेपीए रिपॉजिटरी को परिभाषित कर सकते हैं:

 interface UserRepository extends CrudRepository<User, Integer> { Collection<NamesOnly> findByName(String lastname); } 

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

CUBA में डेटा का चयन कैसे करें

सीयूबीए ढांचे के विकास की शुरुआत से, हमने डेटाबेस के साथ काम करने वाले कोड के हिस्से को अनुकूलित करने का प्रयास किया। CUBA में, हम डेटा एक्सेस API के आधार के रूप में EclipseLink का उपयोग करते हैं। EclipseLink के बारे में क्या अच्छा है कि यह शुरू से ही आंशिक इकाई लोडिंग का समर्थन करती है, और यह इसके और हाइबरनेट के बीच चयन करने में एक निर्णायक कारक था। EclipseLink में, आप JPA 2.1 मानक के प्रदर्शित होने से पहले लोड करने के लिए विशेषताओं को निर्दिष्ट कर सकते हैं। CUBA के पास एक इकाई ग्राफ का वर्णन करने का अपना तरीका है, जिसे CUBA Views कहा जाता है। सीयूबीए एक प्रतिनिधित्व है, बल्कि एक विकसित एपीआई है, आप दूसरों से कुछ प्रतिनिधित्व प्राप्त कर सकते हैं, उन्हें जोड़ सकते हैं, दोनों मास्टर और विस्तार संस्थाओं के लिए आवेदन कर सकते हैं। सीयूबीए विचार बनाने के लिए एक और प्रेरणा यह है कि हम छोटे लेनदेन का उपयोग करना चाहते थे ताकि हम वेब उपयोगकर्ता इंटरफ़ेस में अलग-थलग संस्थाओं के साथ काम कर सकें।
CUBA में, विचार XML फ़ाइल में वर्णित हैं, जैसा कि नीचे दिए गए उदाहरण में है:

 <view class="com.sample.User" extends="_minimal" name="user-minimal-view"> <property name="name"/> <property name="addresses" view="address-street-only-view"/> </property> </view> 

यह दृश्य User इकाई और उसके स्थानीय विशेषता name का चयन करता है, और उनके लिए address-street-only-view लागू करके address-street-only-view का चयन भी करता address-street-only-view । यह सब होता है (ध्यान!) SQL क्वेरी के स्तर पर। जब दृश्य बनाया जाता है, तो आप इसे डेटा चयन में डेटा प्रबंधक वर्ग का उपयोग कर सकते हैं:

 List<User> users = dataManager.load(User.class).view("user-edit-view").list(); 

नेटवर्क ट्रैफ़िक का उपभोग करते हुए, यह दृष्टिकोण ठीक काम करता है, क्योंकि अप्रयुक्त विशेषताओं को केवल डेटाबेस से एप्लिकेशन में स्थानांतरित नहीं किया जाता है, लेकिन, जेपीए के मामले में, एक समस्या है: यह नहीं कहा जा सकता है कि इकाई के कौन से विशेषताओं को लोड किया गया था। “IllegalStateException: Cannot get unfetched attribute [...] from detached object” में एक अपवाद है “IllegalStateException: Cannot get unfetched attribute [...] from detached object” , जो, LazyInit तरह, हमारे फ्रेमवर्क का उपयोग करने वाले सभी लोगों द्वारा सामना किया जाना चाहिए। जेपीए की तरह, यह जाँचने के भी तरीके हैं कि कौन सी विशेषताएँ भरी हुई थीं और कौन सी नहीं हैं, लेकिन, फिर से, ऐसे चेक लिखना एक थकाऊ, श्रमसाध्य कार्य है जो डेवलपर्स को बहुत परेशान करता है। कुछ और का आविष्कार करने की आवश्यकता है ताकि काम के साथ लोगों को बोझ न करें, सिद्धांत रूप में, मशीनें कर सकती हैं।

अवधारणा - सीयूबीए इंटरफेस देखें

लेकिन क्या होगा अगर आप इकाई के ग्राफ और अनुमानों को संयोजित करने का प्रयास करते हैं? हमने इसे देखने की कोशिश करने का फैसला किया और स्प्रिंग प्रोजेक्शन दृष्टिकोण का पालन करने वाली इकाई व्यू इंटरफेस के लिए विकसित इंटरफेस बनाए। इन इंटरफेसों को एप्लिकेशन स्टार्टअप पर CUBA दृश्यों में अनुवादित किया जाता है और इसका उपयोग DataManager में किया जा सकता है। विचार सरल है: हम एक इंटरफ़ेस (या इंटरफेस का एक सेट) का वर्णन करते हैं, जो एक इकाई ग्राफ है।

 interface UserMinimalView extends BaseEntityView<User, Integer> { String getName(); void setName(String val); List<AddressStreetOnly> getAddresses(); interface AddressStreetOnly extends BaseEntityView<Address, Integer> { String getStreet(); void setStreet(String street); } } 

यह ध्यान देने योग्य है कि कुछ विशिष्ट मामलों के लिए, आप स्थानीय इंटरफेस बना सकते हैं, जैसा कि ऊपर दिए गए उदाहरण से AddressStreetOnly के मामले में है, इसलिए आपके आवेदन के सार्वजनिक एपीआई को "प्रदूषित" करने के लिए नहीं।

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

 List<UserMinimalView> users = dataManager.load(UserMinimalView.class).list(); 

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

इस अवधारणा को विकसित करने में, हम एक पत्थर से दो पक्षियों को मारने की कोशिश कर रहे हैं:

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

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

 @MetaProperty default String getNameLowercase() { return getName().toLowerCase(); } 

ध्यान दें कि गणना की गई विशेषताओं को इकाई वर्ग मॉडल से बाहर निकाला जा सकता है और एक विशेष व्यावसायिक तर्क के लिए लागू इंटरफेस में स्थानांतरित किया जा सकता है।

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

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

 UserFullView userFull = userMinimal.reload(UserFullView.class); 

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

अवधारणा को CUBA के लिए एक मॉड्यूल के रूप में डिज़ाइन किया गया है, GitHub से उपयोग का एक उदाहरण डाउनलोड किया जा सकता है ।

निष्कर्ष

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