भंडार में जटिल व्यापार तर्क

Question

मेरे पास एक बहुत जटिल व्यापार तर्क के साथ एक भंडार में एक विधि है। मैंने अभी पढ़ा है कि एक भंडार में कोई व्यावसायिक तर्क नहीं होना चाहिए।

इस विधि से व्यवसाय तर्क को हटाने के लिए मुझे दो अन्य भंडारों के बीच तर्क वितरित करने की आवश्यकता होगी (क्योंकि इसमें दो अन्य इकाइयां शामिल हैं)।

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

Answer 1

जटिल व्यापार तर्क आमतौर पर एक सेवा परत में जाता है। एक सेवा आपके मॉडल पर सीआरयूडी संचालन करने के लिए एक या अधिक भंडारों पर निर्भर हो सकती है। इस प्रकार एक व्यावसायिक संचालन का प्रतिनिधित्व करने वाला एक एकल सेवा संचालन कई सरल संचालन पर निर्भर हो सकता है। फिर आप इस सेवा परत को अपने नियंत्रकों और अन्य अनुप्रयोगों में पुन: उपयोग कर सकते हैं।

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

public interface IProductsRepository { } 
public interface IOrdersRepository { } 
... 

public interface ISomeService 
{ 
    void SomeBusinessOperation(); 
} 

public class SomeServiceImpl: ISomeService 
{ 
    private readonly IProductsRepository _productsRepository; 
    private readonly IOrdersRepository _ordersRepository; 

    public SomeServiceImpl(
     IProductsRepository productsRepository, 
     IOrdersRepository ordersRepository 
    ) 
    { 
     _productsRepository = productsRepository; 
     _ordersRepository = ordersRepository; 
    } 

    public void SomeBusinessOperation() 
    { 
     // TODO: use the repositories to implement the business operation 
    } 
} 

अब सभी अब सिर्फ़ अपने डि ढांचे कॉन्फ़िगर अपने नियंत्रक में इस विशिष्ट सेवा इंजेक्षन करने के लिए है: यहाँ एक उदाहरण है।

public class FooController : Controller 
{ 
    private readonly ISomeService _service; 
    public FooController(ISomeService service) 
    { 
     _service = service; 
    } 

    public ActionResult Index() 
    { 
     // TODO: Use the business operation here. 
    } 
} 

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

Answer 2

मुझे लगता है कि आपका सुपर रिपोजिटरी केवल एक जिम्मेदारी सिद्धांत तोड़ देता है। मैं यथासंभव सरल (केआईएसएस पैटर्न;) भंडार छोड़ दूंगा, और नियंत्रकों और भंडार के बीच अन्य परत बनाएगा, e.q. व्यापार परत

पुन: उपयोग और कोड आसान बनाने के लिए निर्भरता इंजेक्शन पर एक नज़र (आईओसी लागू)

असल में मैं ठोस सिद्धांतों पर एक नजर है करने के लिए सुझाव है कि कर सकते है।

Answer 3

मैं एक डोमेन संचालित डिजाइन दृष्टिकोण का उपयोग करता हूं। डीडीडी पर एक बहुत अच्छी किताब निम्नलिखित है: .NET Domain-Driven Design with C#: Problem-Design-Solution। फाउलर्स एंटरप्राइज़ पैटर्न और इवांस डोमेन संचालित डिजाइन पुस्तकें भी देखें। मूल विचार यह है कि एक भंडार मूल रूप से आधारभूत संरचना है। सभी डोमेन तर्क आपके मॉडल में जाते हैं।

उदाहरण भंडार विधि इस प्रकार है:

public void InsertAddresse(Company company) 
{ 
    foreach (Address address in company.Addresses) 
    { 
     this.InsertAddress(address, company.Key, (company.HeadquartersAddress == address)); 
    } 
} 

दूसरी ओर एक मॉडल वस्तु इस तरह दिखता है:,

public class Contact : Person, IAggregateRoot, IHasAddresses 
{ 
    private string jobTitle; 
    private string email; 
    private string phoneNumber; 
    private string mobilePhoneNumber; 
    private string faxNumber; 
    private string remarks; 
    private Company currentCompany; 
    private IList<Address> addresses; 

    public Contact() 
     : this(null) 
    { 
    } 

    public Contact(object key) 
     : this(key, null, null) 
    { 
    } 

    public Contact(object key, string firstName, string lastName) 
     : base(key, firstName, lastName) 
    { 
     this.jobTitle = string.Empty; 
     this.email = string.Empty; 
     this.phoneNumber = string.Empty; 
     this.mobilePhoneNumber = string.Empty; 
     this.faxNumber = string.Empty; 
     this.remarks = string.Empty; 
     this.currentCompany = null; 
     this.addresses = new List<Address>(); 
    } 

    public string JobTitle 
    { 
     get { return this.jobTitle; } 
     set { this.jobTitle = value; } 
    } 

    public string Email 
    { 
     get { return this.email; } 
     set { this.email = value; } 
    } 

    public string PhoneNumber 
    { 
     get { return this.phoneNumber; } 
     set { this.phoneNumber = value; } 
    } 

    public string MobilePhoneNumber 
    { 
     get { return this.mobilePhoneNumber; } 
     set { this.mobilePhoneNumber = value; } 
    } 

    public string FaxNumber 
    { 
     get { return this.faxNumber; } 
     set { this.faxNumber = value; } 
    } 

    public string Remarks 
    { 
     get { return this.remarks; } 
     set { this.remarks = value; } 
    } 

    public Company CurrentCompany 
    { 
     get { return this.currentCompany; } 
     set { this.currentCompany = value; } 
    } 

    public IList<Address> Addresses 
    { 
     get { return this.addresses; } 
    } 

    protected override void Validate() 
    { 
     //some logic here 
    } 

    protected override BrokenRuleMessages GetBrokenRuleMessages() 
    { 
     return new ContactRuleMessages(); 
    } 
}