2010-08-31 10 views
12

कल्पना कीजिए, एक घटना इकाई एक स्थिति एंटिटी संदर्भ:जेपीए बेस्ट प्रैक्टिस: स्टेटिक लुक संस्थाओं

@Entity 
@Table(name = "event") 
public class Event() 
{ 
    @Id 
    @Column(name = "id", nullable = false) 
    private long id; 
    ... 

    @ManyToOne 
    @JoinColumn(name = "status_code", nullable = false) 
    private Status status; 
} 


@Entity 
@Table(name = "status") 
public class Status() 
{ 
    @Id 
    @Column(name = "code", nullable = false) 
    private String code; 

    @Column(name = "label", nullable = false, updatable = false) 
    private String label; 
} 

स्थिति एक छोटी सी मेज 'status' के लिए मैप किया गया है। स्थिति एक विशिष्ट संदर्भ डेटा/लुकअप इकाई है।

code label 
    ----- -------------- 
    CRD Created 
    ITD Initiated 
    PSD Paused 
    CCD Cancelled 
    ABD Aborted 

मुझे यकीन है कि अगर यह एक अच्छा विचार एक इकाई के रूप स्थिति मॉडल करने के लिए है नहीं कर रहा हूँ। यह एक इकाई के रूप में अधिक स्थिरांक की एक गणना की तरह लगता है ...

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

दूसरी तरफ, यदि मैं किसी ईवेंट में कोई विशेष स्थिति सेट करना चाहता हूं, तो मैं केवल उस स्थिर स्थिति को असाइन नहीं कर सकता जो मुझे दिमाग में है। मुझे पहले सही इकाई को देखना है:

event.setStatus(entityManager.find(Status.class, "CRD")) 

क्या मैं उपरोक्त कोड खंड से बच सकता हूं? मैं निष्पादन दंड के लिए affraid हूँ और यह बहुत भारी लग रहा है ...

  • मैं साथ रीड-ओनली विशेषताओं बातें tweak करने के लिए है?
  • क्या मैं इन लुकअप इकाइयों को प्रीफेच कर सकता हूं और उन्हें स्थिरांक के रूप में उपयोग कर सकता हूं?
  • क्या मुझे एक महत्वपूर्ण जेपीए सुविधा याद आई?
  • ...?

सभी विचार/सुझाव/सिफारिशों का स्वागत है!

धन्यवाद! जे

उत्तर

3

क्या मैं उपरोक्त कोड खंड से बच सकता हूं? मैं प्रदर्शन दंड के लिए डरता हूं और यह बहुत भारी दिखता है?

ठीक है, आप एक enum बजाय इस्तेमाल कर सकते हैं। मैं वास्तव में नहीं देखता कि आप वास्तव में क्यों नहीं करते हैं।

लेकिन क्या तुम सच में एक इकाई उपयोग करना चाहते हैं, तो यह 2 स्तर कैशिंग के लिए एक आदर्श उम्मीदवार होगा और यह आपके प्रदर्शन चिंता का विषय का समाधान होगा।

+1

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

+0

मुझे दूसरे-स्तर के कैश पर नज़र डालना होगा। दुर्घटना से, क्या आप किसी भी उपकरण के बारे में जानते हैं जो हाइबरनेट में दूसरे स्तर के कैश की आसान निगरानी की अनुमति देता है? – Jan

+0

@ जेन राइट, आपके पास एनम के साथ डेटाबेस में लेबल नहीं होगा। लेकिन मैं वास्तव में कोड में नहीं, 'बनाया', 'आरंभ', आदि का उपयोग करता हूं, कोड नहीं। वैसे भी, आपके लिए एक इकाई का उपयोग करना वास्तव में बेहतर हो सकता है। और उस मामले में, @ जोर्न सलाह एक अच्छा है। फिर भी, यह केवल पढ़ने वाली इकाई एल 2 कैशिंग के लिए एक आदर्श उम्मीदवार होगी। निगरानी के संबंध में, यह एल 2 कैश प्रदाता पर निर्भर करता है। –

9

आप entityManager.getReference(Status.class, "CRD") इस्तेमाल कर सकते हैं, अगर यह केवल एक विदेशी कुंजी सेट करने के लिए प्रयोग किया जाता है डेटाबेस से इकाई को नहीं लाया जा सकता है।

+0

अच्छा! यही वह संकेत है जिसे मैं ढूंढ रहा था। – Jan

संबंधित मुद्दे