कृपया नीचे दिए गए उदाहरण पर विचार करें:

एक वेब एप्लिकेशन हर लॉग इन यूजर के लिए एक यूजर ऑब्जेक्ट बनाता है। इस ऑब्जेक्ट में firstName, lastName ... के लिए सरल String गुण हैं ...

प्रत्येक उपयोगकर्ता का car भी हो सकता है। गौर करें कि उपयोगकर्ता car प्राप्त करना बहुत महंगा है, इसलिए हम उपयोगकर्ता लॉग इन करते समय उपयोगकर्ता कार को सेट नहीं करना पसंद करते हैं। इसके बजाय हम उपयोग की स्थिति में कार की आवश्यकता होने पर उसे प्राप्त करना चाहते हैं।

इसे लागू करने के लिए हमने एक यूजर पूजो बनाया है:

public class User() {
  private String FirstName;
  private String LastName;   
  private Car car;
  //Here we have the service object, this could be injected with spring or JEE
  private CarServices carServices;

  public Car getCar() {
    //If the car is not fetched yet, go on and get it from your service
    if (car == null) {
      car = carServices.getCarFromDB(...)
    }
    return car;
  }

}

लॉगिन के बाद प्रारंभिक उपयोगकर्ता के लिए:

User newUser = new User();
newUser.setFirstName("foo");
newUser.setLastName("bar");
//We just let user have service, so he can use this service latter
newUser.setCarServices( new CarServices() );

और हर उपयोग के मामले में उपयोगकर्ता की कार की जरूरत है, इसे आसानी से प्राप्त कर सकते हैं:

newUser.getCar()

हालाँकि, मुझे तर्क दिया गया है कि इस तरह से मेरी उपयोगकर्ता वस्तु किसी भी तरह से एक साधारण पूजो नहीं है और यह एक अच्छा दृष्टिकोण नहीं है।

मैं इस आवश्यकता को बेहतर तरीके से कैसे प्राप्त कर सकता हूं।

3
Alireza Fattahi 22 नवम्बर 2015, 08:44

2 जवाब

सबसे बढ़िया उत्तर

मुझे तर्क दिया गया है कि इस तरह से मेरी उपयोगकर्ता वस्तु एक साधारण पूजो नहीं है

आपके प्रश्न का उत्तर देने के लिए मैं सबसे पहले इतिहास में थोड़ा पीछे जाना चाहूंगा।

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

आपका User वर्ग सिर्फ मानक जावा पर निर्भर करता है और इसलिए यह एक पोजो है।

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

यदि आप CarServices निर्भरता को User वर्ग से हटाना चाहते हैं, तो आप हाइबरनेट या एक jpa कार्यान्वयन की तरह Car आलसी लोडिंग प्रॉक्सी को लागू कर सकते हैं।

कम से कम यहाँ मेरे कुछ विचार सेम, पीओजोस, एनीमिक और रिच डोमेन मॉडल हैं।

जब आप अन्य डेवलपर्स के साथ चर्चा करते हैं तो उम्मीद है कि यह आपकी मदद करता है।

3
René Link 22 नवम्बर 2015, 09:52

एक कार के संदर्भ के बजाय, आप एक कार आपूर्तिकर्ता वस्तु के संदर्भ का उपयोग कर सकते हैं जिसका कार्यान्वयन प्राप्त किए गए पहले परिणाम को कैश कर सकता है (गुवा के Supplier} और MemoizingSupplier कक्षाएं देखें)। ऐसा करने से, आप User से इस तथ्य को छिपाते हैं कि इसकी कार तात्कालिक समय पर मौजूद नहीं हो सकती है या नहीं, और इसलिए इसके कार्यान्वयन को सरल बनाता है (गेट्टर विधि में कोई और तर्क नहीं)।

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

यह एक POJO के User वर्ग को अधिक नहीं बनायेगा (जैसा कि ऊपर दिए गए पहले उत्तर में बताया गया है), लेकिन जो लोग आपके समाधान के बारे में तर्क देते हैं, वे इसे बेहतर और कम कसकर युग्मित होने के कारण इसे बेहतर पसंद कर सकते हैं।

1
Thomas Naskali 8 मार्च 2016, 06:30