एक और सेवा परत खराब अभ्यास के लिए एक सेवा संदर्भ गुजर रहा है?

Question

मैं एक सी # MVC अनुप्रयोग है कि मैं निम्नलिखित तरीके से तोड़ मिल गया है: -> नियंत्रक -> सेवा - देखें> भंडार

मुझे लगता है कि वापस आ रहा है एक अनूठा दृश्य मॉडल होने प्रत्येक दृश्य के साथ पतली नियंत्रक अभ्यास का उपयोग प्रासंगिक सेवा से।

त्वरित उदाहरण: दृश्य:/NewAppointment/चरण 1

इसके controler इस प्रकार दिखाई देगा:

public ActionResult Step1() 
{ 
    return View(_appointmentService.Step1GetModel()); 
} 

और नियुक्ति सेवा परत इस प्रकार दिखाई देगा:

public Step1Model Step1GetModel() 
{ 
    return new Step1Model(); 
} 

इस प्रकार

मेरे आवेदन के माध्यम से उपयोग में कई अलग-अलग सेवा परतें हैं, प्रत्येक एक अलग इंटरफेस को लागू करता है।

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

उदाहरण:

मैं डिफ़ॉल्ट रूप से ग्राहक की जानकारी के साथ मेरे विचार मॉडल को भरने के लिए चाहते हैं। दो तरह से मैं ऐसा करने का देख रहे हैं:

नियुक्ति सेवा करने के लिए एक ग्राहक इंटरफ़ेस संदर्भ दर्रा, और फिर नियुक्ति सेवा कॉल ग्राहक सेवा में उचित GetCustomer विधि हैं ...

कोड में:

private ICustomerService _customerService; 
private IAppointmentService _appointmentService; 

public ActionResult Step1() 
{ 
    var viewModel = _appointmentService.Step1GetModel(_customerService); 
    return View(viewModel); 
} 

या

नियंत्रक ग्राहक होने का तर्क संभाल करते हैं, तो नियुक्ति सेवा करने के लिए है कि परिणाम गुजरती हैं।

कोड में:

private ICustomerService _customerService; 
private IAppointmentService _appointmentService; 

public ActionResult Step1() 
{ 
    var customer = _customerService.GetCustomer(); 
    var viewModel = _appointmentService.Step1GetModel(customer); 
    return View(viewModel); 
} 

मैं फटे कर रहा हूँ के रूप में जो बेहतर अभ्यास होगा। पहला नियंत्रक अच्छा और पतला रखता है, लेकिन नियुक्ति सेवा और ग्राहक सेवा के बीच एक अंतर-सेवा निर्भरता बनाता है। दूसरा नियंत्रक में अधिक तर्क डालता है, लेकिन सेवाओं को पूरी तरह से स्वतंत्र रखता है।

किसी के पास विचार है कि कौन सा बेहतर अभ्यास होगा?

धन्यवाद ~

Answer 1

के बारे में सोच उसके विशुद्ध रूप से धारणात्मक मुझे नहीं लगता कि यह आपके view models के बारे में अपने services पता करने के लिए कुछ भी करने के लिए समझ में आता है है। पहले स्थान पर नियंत्रक होने के मुख्य कारणों में से एक है अपने व्यू तर्क को अपने व्यावसायिक तर्क से अलग करना, लेकिन यदि आपकी सेवाएं विशिष्ट डेटा को वापस लौट रही हैं तो वे स्वाभाविक रूप से आपके व्यावसायिक तर्क से बंधे हैं।

आदर्श रूप में मैं इस तरह देखने के लिए विधि उम्मीद थी:

public ActionResult Step1() 
{ 
    var customer = _customerService.GetCustomer(); 
    var appointment = _appointmentService.GetAppointmentFor(customer); 

    var viewModel = new Step1ViewModel(customer, appointment); 

    return View(viewModel); 
} 

हालांकि अधिक सीधे आपके सवाल का जवाब करने के लिए, मुझे लगता है कि अपनी सेवाओं को एक-दूसरे के बारे में जानने के लिए यह ठीक है, वे का हिस्सा हैं एक ही अवधारणात्मक परत।

इसके अलावा, एक और बात ...

ऐसा लगता है कि आप समानांतर वर्ग पदानुक्रम का एक बहुत केवल सहायता की जरूरत सेवाओं, खजाने और नियंत्रकों के साथ क्या। ऐसा लगता है कि कुछ करने के लिए काम पैटर्न की इकाई और एक शक्तिशाली ORM की तरह कुछ का उपयोग करने के लिए और अधिक समझ बनाने सकता है:

public MyController(IUnitOfWork unitOfWork)... 

public ActionResult Step1() 
{ 
    var customer = unitOfWork.Find<Customer>(); 
    var viewModel = new Step1ViewModel(customer.Appointment); 
    return View(viewModel); 
} 

सब के बाद, अपने आवेदन के मूल्य सेवाओं में नहीं, मॉडल में है।