किस परत में विशिष्टता पैटर्न वस्तुओं को "नया 'होना चाहिए?

Question

इसलिए, मैंने यहां विशिष्टता पैटर्न के बारे में कुछ पोस्ट देखी हैं, और अभी तक इसका कोई जवाब नहीं मिला है।

मेरा प्रश्न एक एन-स्तरित वास्तुकला में है, जहां मुझे वास्तव में विनिर्देशों को "नया" होना चाहिए?

1. मैं उन्हें अपने सेवा परत में डाल सकता है (उर्फ, आवेदन परत यह कभी कभी कहा जाता है ... मूल रूप से, कुछ एक .aspx कोड-पीछे से बात करेंगे), लेकिन मुझे लगता है कि, मैं ऐसा करके मन मैं व्यापार नियमों को डोमेन से बाहर निकालने दे रहा हूं। यदि डोमेन ऑब्जेक्ट्स को किसी अन्य तरीके से एक्सेस किया जाता है (सेवा परत के अलावा), डोमेन ऑब्जेक्ट्स अपने व्यवसाय नियमों को लागू नहीं कर सकता है।

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

3. मैं विधि इंजेक्शन (कभी-कभी "डबल डिस्पैच" के रूप में संदर्भित) के माध्यम से विशिष्टता इंजेक्ट कर सकता हूं, और स्पष्ट रूप से उस विधि को अपने व्यापार नियम को लागू करने के लिए इंजेक्शन विशिष्टता को समाहित करता है।

4. एक "डोमेन सेवा" कक्षा बनाएं, जो कन्स्ट्रक्टर इंजेक्शन के माध्यम से विशिष्टता लेती है, और उसके बाद सर्विस लेयर डोमेन ऑब्जेक्ट को समन्वयित करने के लिए डोमेन सेवा का उपयोग करने दें। यह मेरे लिए ठीक लगता है, क्योंकि विशिष्टता द्वारा लागू नियम अभी भी "डोमेन" में है, और डोमेन सेवा वर्ग को डोमेन ऑब्जेक्ट की तरह बहुत अधिक नामित किया जा सकता है। यहां बात यह है कि मुझे लगता है कि मैं कक्षाओं और कोड के बहुत सारे लिख रहा हूं, बस विशिष्टता पैटर्न को "ठीक से" लागू करने के लिए।

इसमें जोड़ें, प्रश्न में विशिष्टता को यह निर्धारित करने के लिए एक रिपोजिटरी की आवश्यकता होती है कि यह "संतुष्ट" है या नहीं।

यह संभावित रूप से प्रदर्शन समस्याओं का कारण बन सकता है, esp। अगर मैं कन्स्ट्रक्टर इंजेक्शन का उपयोग करता हूं बी/सी उपभोग करने वाला कोड ऐसी संपत्ति को कॉल कर सकता है जो शायद विशिष्टता को लपेटता है, और वह बदले में डेटाबेस को कॉल कर रहा है।

तो लेखों के किसी भी विचार/विचार/लिंक?

नए होने और विनिर्देशों का उपयोग करने के लिए सबसे अच्छी जगह कहां है?

Answer 1

लघु जवाब:

आप तो वहाँ मुख्य रूप से अपने सेवा परत में विनिर्देशों का उपयोग करें।

लांग जवाब: सब से सबसे पहले, यहाँ दो सवाल है:

जहाँ आपके चश्मा रहना चाहिए, और जहां वे new'd किया जाना चाहिए?

बस अपने भंडार इंटरफेस की तरह, आपकी चश्मे डोमेन परत में रहनी चाहिए, क्योंकि वे सभी डोमेन डोमेन विशिष्ट हैं। question on SO है जो रिपोजिटरी इंटरफेस पर इसकी चर्चा करता है।

हालांकि उन्हें नया क्यों किया जाना चाहिए? ठीक है, मैं अपने खजाने पर LinqSpecs का उपयोग करें और ज्यादातर कभी अपने भंडार पर तीन तरीकों है:

public interface ILinqSpecsRepository<T> 
{ 
    IEnumerable<T> FindAll(Specification<T> specification); 
    IEnumerable<T> FindAll<TRelated>(Specification<T> specification, Expression<Func<T, TRelated>> fetchExpression); 
    T FindOne(Specification<T> specification); 
} 

मेरे प्रश्नों के बाकी मेरी सेवा परत में निर्माण कर रहे हैं। यह रिपोजिटरी को GetUserByEmail, GetUserById, GetUserByStatus इत्यादि जैसे विधियों से फूला हुआ रखने से रोकता है मेरी सेवा में, मैं अपने चश्मा को नया करता हूं और उन्हें अपने भंडार के FindAll या FindOne विधियों में भेजता हूं। उदाहरण के लिए:

public User GetUserByEmail(string email) 
{ 
    var withEmail = new UserByEmail(email); // the specification 
    return userRepository.FindOne(withEmail); 
} 

और यहाँ विशिष्टता है:

public class UserByEmail : Specification<User> 
{ 
    private readonly string email; 

    public UserByEmail(string email) 
    { 
     this.email = email; 
    } 

    #region Overrides of Specification<User> 

    public override Expression<Func<User, bool>> IsSatisfiedBy() 
    { 
     return x => x.Email == email; 
    } 

    #endregion 
} 

तो अपने सवाल का जवाब देने, चश्मा सेवा परत में new'd कर रहे हैं (मेरी किताब में)।

मैं केवल बात यह है कि मॉडल वर्गों में इंजेक्ट किया जाना चाहिए की तरह महसूस "सेवाओं"

IMO आप डोमेन संस्थाओं में कुछ भी इंजेक्शन नहीं किया जाना चाहिए रहे हैं।

इसमें जोड़ें कि प्रश्न में विशिष्टता को यह निर्धारित करने के लिए एक रिपोजिटरी की आवश्यकता होती है कि यह "संतुष्ट" है या नहीं।

यह code smell है। मैं वहां आपके कोड की समीक्षा करूंगा। एक विशिष्टता निश्चित रूप से एक भंडार की आवश्यकता नहीं है।

Answer 2

एक विनिर्देश एक व्यापार नियम की कार्यान्वयन जांच है। यह डोमेन परत पूर्ण स्टॉप में मौजूद होना है।

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

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

आखिरकार, मेरा जवाब यह मान रहा है कि जिस प्रणाली पर आप काम कर रहे हैं वह कम से कम कुछ जटिल है। यदि यह एक बहुत ही सरल प्रणाली है, तो एक अवधारणा के रूप में डोमेन संचालित डिज़ाइन शायद शीर्ष पर भी है। हालांकि मेरी राय में कोडबेस के बावजूद टेस्टेबिलिटी, पठनीयता, एसओसी इत्यादि जैसी कुछ अवधारणाओं का सम्मान किया जाना चाहिए।