2009-03-04 18 views
6

सॉफ्टवेयर मैं "आवेदन" शामिल होगी दूसरी स्थिति के बीच एक बहुत स्विचिंग का निर्माण किया जाएगा बनाम। कुछ कार्य किए जा सकते हैं एक आवेदन की स्थिति पर निर्भर करता है। मैं स्थिति के रूप में enum का उपयोग करEnum बनाम लुक-अप तालिका बनाम Enum प्रतिबिंब राज्य पैटर्न

public class Application 
{ 
    public int Id {get;set;} 
    public Status {get;set;} 
} 
public enum Status 
{ 
    [Description("New")]New = 1, [Description("Closed")]Closed = 2 
} 

के बारे में सोच रहा था लेकिन फिर मैंने सोचा कि शायद यह डेटाबेस में लुकअप तालिका का उपयोग करने के रूप में स्थिति अद्यतन हो जाता है/पुनः आदेश दिया अक्सर

table status (id int pk, desc string, sort_order int) 
table application (id int pk, status_id int fk) 

में अच्छा है मेरी मामले में मुझे

if (application.Status == Status.New) 
{ //do something } 
else if (application.Status == Status.Closed) 
{ //do other things } 

मुझे लगता है कि उपर्युक्त मामले enum के साथ करना आसान है। हालांकि जब स्थिति सॉर्ट ऑर्डर या विवरण अपडेट करने की बात आती है तो यह काफी कठिन होगा।

क्या मुझे लुकअप टेबल से मूल्यों के आधार पर गतिशील रूप से enum बनाने के लिए प्रतिबिंब का उपयोग करना चाहिए? या मुझे राज्य पैटर्न का उपयोग करना चाहिए? एनम रिएक्शन के साथ मैं जो समस्या देखता हूं वह प्रदर्शन प्रभाव है। और राज्य पैटर्न बहुत अनावश्यक कोड उत्पन्न कर सकता है।

आपको क्या लगता है? अग्रिम में धन्यवाद!

उत्तर

3

मैं एक स्थिति वर्ग कि मतभेद होता है बनाने के लिए, और उन फोन चाहते हैं। तो (अजगर में):

class StatusZero(object): 
    def call_me(self, app): 
     print 'Hello, from ' + app.name 
     return db.prepare_specific_status_zero_request() 


class StatusOne(object): 
    def call_me(self, app): 
     print 'Hi, from ' + app.name 
     return db.prepare_specific_status_one_request() 

states = { 'status_zero' : StatusZero(), 'status_one' : StatusOne() } 

class Application(object): 
    name = 'My App' 
    status = states['status_zero'] 

    def change_state(self, state): 
     status = state 

    def call_me(self): 
     state_key = self.status.call_me(self) 
     self.change_state(states[state_key]) 

, फास्ट कार्यक्षमता बंटे रखने के लिए, और राज्यों के बीच एक उचित वंशानुक्रम स्वरूप के साथ कार्य करता है जो भिन्न नहीं हैं साझा कर सकते हैं आसान।

+0

कैसे यू डाटाबेस से वापस लाने संभाल करते हैं और वस्तु के लिए कलाकारों में आवेदन की स्थिति को बचाने के लिए एक enum या लुकअप तालिका की जरूरत है अगर मैंने उत्तर 3 में उल्लेख किया है तो बिना किसी अन्य कथन के बिट? – Jeff

+0

मुझे लगता है कि मुझे इस मुद्दे को समझने में कठिनाई है। प्रत्येक स्थिति ऑब्जेक्ट में आपके इच्छित कोड हो सकते हैं - यदि आवश्यक हो तो हार्ड वायर्ड कास्ट भी शामिल है। आवेदन वस्तु वही रह सकती है; यह कॉल को प्रेषित करता है जो आंतरिक स्थिति से भिन्न होता है। –

+0

मेरी मुद्दों हाथ अगर लिखा से बचने के लिए कैसे है और कुछ बयान जब सही स्थिति में वस्तु को वापस डेटा तालिका डाली, अपने उदाहरण में, आप कैसे यदि किसी और बयान के बिना StatusZero या StatusOne वापस करने के लिए डेटा पंक्ति डाली करते हैं? – Jeff

7

आप अपने कोड इस चेक के साथ हर जगह

if (application.Status == Status.New) 
{ //do something } 
else if (application.Status == Status.Closed) 
{ //do other things } 

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

स्थिति बदलने के लिए, राज्य के पैटर्न के साथ कुछ भी नहीं मिला है। तो आप जो भी दृष्टिकोण सुरुचिपूर्ण है का उपयोग कर सकते हैं।

0

मेरी समझ यह है कि राज्य पैटर्न केवल यूआई के लिए या स्मृति में केवल निष्पादन के लिए काफी अच्छा है, जहां मेरी स्थिति में आवेदन तालिका से डेटा वापस प्राप्त करते समय, अभी भी यह बताने की आवश्यकता है कि किस वस्तु को कास्ट करना है।

public AbstractApplication convert_db_application_to_object(obj db_application) 
{ 
    AbstractApplication app; 
    if (db_application.Status == (int)Status.New) 
     app = application_factory.create(application_state_new); 
    else if(db_application.Status == (int)Status.Closed) 
     app = application_factory.create(application_state_closed); 

    return app; 
} 

मैं इस एक सुरुचिपूर्ण समाधान के रूप में नहीं दिख रहा है के रूप में मैं अभी भी या तो डेटाबेस