आप इस सीआरयूडी कक्षा का नाम क्या नाम देंगे?

Question

SomethingManager यहां से जाल से बचने की कोशिश कर रहे हैं ...

मान लें कि मैं एक उपयोगकर्ता संपादक लिखने जा रहा हूं जो प्रशासकों को सिस्टम में उपयोगकर्ताओं को बनाने की अनुमति देगा। सुंदर बुनियादी कार्यक्षमता - मौजूदा उपयोगकर्ताओं की एक सूची देखें, एक नया उपयोगकर्ता बनाएं, मौजूदा उपयोगकर्ता को अपडेट करें, उपयोगकर्ता को हटाएं।

आइए हम यह भी कहें कि मैं इन बुनियादी सीआरयूडी संचालन को संभालने के लिए "व्यवसाय" कक्षा लिखने का निर्णय लेता हूं। फिर,

public interface ISomeUsefulName 
{ 
    IList<User> FetchUsers(); 
    User FetchUser(int userId); 
    bool SaveUser(User user); 
    bool DeleteUser(int userId); 
} 

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

मेरा सवाल है, मुझे इस कक्षा का नाम क्या होना चाहिए? क्या यह वर्ग बहुत अधिक कर रहा है और इसलिए मुझे इसे कई वर्गों में विभाजित करना चाहिए?

Answer 1

नामकरण मुश्किल अगर SRP :) का सम्मान नहीं कर रहा है लेकिन सदस्यों नामकरण अक्सर दुरुपयोग किया जाता है।

आपके मामले में मैं कुछ इस तरह करेंगे:

• कार्यान्वयन की जिम्मेदारी हठ की निर्दिष्ट अनुबंध कवर करने के लिए है
• "जो" आग के अंतर्गत है

आवाज के बिना सोचता - उपयोगकर्ता के लिए दृढ़ता की जाती है और एक प्रासंगिक नाम IUserRepository हो सकता है - सीआरयूडी के लिए विधियां अधिक नहीं हैं - इस तथ्य के कारण कि IUserRepository उपयोगकर्ता के लिए है,

public interface IRepository<TYPE, KEY>{ 
    IList<TYPE> GetAll(KEY key); 
    TYPE GetById(KEY key); 
    void Save(TYPE obj); 
    void Update(TYPE obj); 
    void Delete(Key key); 
} 

यह मुश्किल है: क्योंकि यह ब्रेक सामान्य उपयोग ढंग

जादू यहाँ है ... बस ऐसा करने UserSave, UserUpdate के लिए आवश्यक नहीं है? एक कस्टम के साथ क्या करना है?

public interface IUserRepository : IRepository<User, int> 
{ 
    IList<User> GetAllMyFavorites(ICriteria crit); 
    IList<Events> GetHistoryByUser(User user); 
} 

एक आईओसी कंटेनर का उपयोग कर कोड में आप आसानी से

public UserController { 
    private _userRepository = null; 
    private _eventsRepository = null; 

    public UserController(IUserRepository userRepository, 
    IRepository<Events,int> eventsRepository) 
    // if you are doing here just CRUD use the generic signature 
    { 
    _userRepository = userRepository; 
    _eventsRepository = eventsRepository; 
    } 

    public MarkItAsGoldPartener(int userId){ 
    var user = userRepository.GetById(userId); 
    user.PartnerType = PartnerTypes.Gold; 
    userRepository.Save(user); // the user in member name is useless 
    eventsRepository.Save(new Event(){Message = "The user" + UserId + "is golden" }); 
    } 
} 

सौभाग्य :)

Answer 2

मेरी प्राथमिकता IUserStorage या IUserStore

Answer 3

क्यों न सिर्फ IUserCRUD हो सकता है? सीआरयूडी ने 10 प्रबंधनों को 'प्रबंधित' करने के लिए चुना है।

Answer 4

इसे "उपयोगकर्ता" (या "अधिकृत उपयोगकर्ता" या "संग्रहऑफ यूज़र") कहने के बारे में कैसे?

Answer 5

IUserRepository - Repository पैटर्न के रूप में।

Answer 6

मैं क्रिसवे के कॉल को सिर्फ "उपयोगकर्ता" नाम देने के लिए दूसरा कर रहा हूं।

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

Answer 7

IUserRepository या IUserServices।

Answer 8

तथ्य यह है कि आपको नामकरण में परेशानी हो रही है, यह एक विशाल लाल झंडा होना चाहिए जो गलत है।

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

public interface IUserList 
{ 
    IList<User> FetchUsers(); 
} 

public interface IUser 
{ 
    User FetchUser(int userId); 
} 

public interface IUserStore 
{ 
    bool SaveUser(User user); 
    bool DeleteUser(int userId); 
} 

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

Answer 9

यह एक सामान्य इंटरफ़ेस बन सकता है।

ICrud<T> { } 

या IUserStore द्वारा प्रेरित।

IStore<T> { } 

Answer 10

मैं UserActions साथ जाना चाहते हैं कर सकते हैं। यह उस कार्यक्षमता के सेट का वर्णन करता है जिसे आप करना चाहते हैं; यह इसे एक संग्रह कहने के जाल से बचाता है (क्योंकि यह वास्तव में कुछ भी एकत्र नहीं करता है, बस संग्रह को पुनर्प्राप्त करता है)।

लेकिन मैं इस वर्ग को इस रूप में पहली जगह पर पुनर्विचार भी करूँगा। ऐसा लगता है कि आप जो जगह बनाने की कोशिश कर रहे हैं वह दृढ़ता प्रबंधक है; क्या कोई अन्य प्रकार की वस्तुएं हैं जिन्हें आप इस तरह से जारी रखना चाहते हैं? क्या आप किसी भी सामान्य कार्यक्षमता को निकाल सकते हैं जिसे तब बेस क्लास में लिया जा सकता है? शायद एक "PersistenceManager" कक्षा या somesuch? फिर, यदि यह बिल्कुल जरूरी है (और मुझे यकीन नहीं है कि यह होगा), तो आप "UserPersistenceManager" प्राप्त कर सकते हैं जो उपयोगकर्ता ऑब्जेक्ट्स पर अकेले काम करेगा। (मेरा मानना ​​है कि यह आवश्यक नहीं हो सकता है क्योंकि आप PersistenceManager से केवल वही सब कुछ करने में सक्षम हो सकते हैं, केवल आपका विशिष्ट कार्यान्वयन आपको बता सकता है कि, हालांकि।)