मैं हाल ही में CQRS / MediatR में देख रहा हूं। लेकिन जितना अधिक मैं इसे पसंद करता हूं उतना कम मैं इसे नीचे ड्रिल करता हूं। शायद मैंने कुछ / सब कुछ गलत समझा है।
तो यह आपके नियंत्रक को इस तक कम करने का दावा करके भयानक शुरू होता है
public async Task<ActionResult> Edit(Edit.Query query)
{
var model = await _mediator.SendAsync(query);
return View(model);
}
जो पतली नियंत्रक दिशानिर्देश के साथ पूरी तरह से फिट बैठता है। हालाँकि यह कुछ महत्वपूर्ण महत्वपूर्ण विवरणों को छोड़ देता है - त्रुटि से निपटने।
Loginनए MVC प्रोजेक्ट से डिफ़ॉल्ट कार्रवाई को देखने देता है
public async Task<IActionResult> Login(LoginViewModel model, string returnUrl = null)
{
ViewData["ReturnUrl"] = returnUrl;
if (ModelState.IsValid)
{
// This doesn't count login failures towards account lockout
// To enable password failures to trigger account lockout, set lockoutOnFailure: true
var result = await _signInManager.PasswordSignInAsync(model.Email, model.Password, model.RememberMe, lockoutOnFailure: false);
if (result.Succeeded)
{
_logger.LogInformation(1, "User logged in.");
return RedirectToLocal(returnUrl);
}
if (result.RequiresTwoFactor)
{
return RedirectToAction(nameof(SendCode), new { ReturnUrl = returnUrl, RememberMe = model.RememberMe });
}
if (result.IsLockedOut)
{
_logger.LogWarning(2, "User account locked out.");
return View("Lockout");
}
else
{
ModelState.AddModelError(string.Empty, "Invalid login attempt.");
return View(model);
}
}
// If we got this far, something failed, redisplay form
return View(model);
}
परिवर्तित करना जो हमें वास्तविक विश्व की समस्याओं का एक समूह प्रदान करता है। याद रखें कि लक्ष्य इसे कम करना है
public async Task<IActionResult> Login(Login.Command command, string returnUrl = null)
{
var model = await _mediator.SendAsync(command);
return View(model);
}
इसका एक संभावित समाधान एक के CommandResult<T>बजाय वापस लौटना modelऔर फिर CommandResultएक पोस्ट एक्शन फिल्टर में संभालना है । जैसा कि यहां चर्चा की गई है ।
एक कार्यान्वयन CommandResultइस तरह हो सकता है
public interface ICommandResult
{
bool IsSuccess { get; }
bool IsFailure { get; }
object Result { get; set; }
}
हालाँकि यह वास्तव में Loginकार्रवाई में हमारी समस्या का समाधान नहीं करता है, क्योंकि कई विफलता राज्य हैं। हम इन अतिरिक्त विफलता राज्यों को जोड़ सकते हैं, ICommandResultलेकिन यह एक बहुत ही फूला हुआ वर्ग / इंटरफ़ेस के लिए एक शानदार शुरुआत है। कोई कह सकता है कि यह एकल जिम्मेदारी (एसआरपी) का अनुपालन नहीं करता है।
एक और समस्या है returnUrl। हमारे पास यह return RedirectToLocal(returnUrl);कोड है। किसी तरह हमें कमांड की सफलता की स्थिति के आधार पर सशर्त तर्कों को संभालने की आवश्यकता है। जबकि मुझे लगता है कि यह किया जा सकता है (मुझे यकीन नहीं है कि अगर मॉडलबिंडर FromBody और FromQuery ( returnUrlFromQuery से है) एक ही मॉडल के लिए तर्क दे सकता है)। कोई केवल यह सोच सकता है कि सड़क के नीचे किस तरह के पागल परिदृश्य आ सकते हैं।
लौटे त्रुटि संदेशों के साथ मॉडल सत्यापन भी अधिक जटिल हो गया है। इसे एक उदाहरण के रूप में लें
else
{
ModelState.AddModelError(string.Empty, "Invalid login attempt.");
return View(model);
}
हम मॉडल के साथ एक त्रुटि संदेश देते हैं। इस तरह की बात एक Exceptionरणनीति का उपयोग करके नहीं की जा सकती (जैसा कि यहां बताया गया है ) क्योंकि हमें मॉडल की आवश्यकता है। शायद आप मॉडल प्राप्त कर सकते हैं, Requestलेकिन यह एक बहुत ही शामिल प्रक्रिया होगी।
तो सब सब में मैं एक कठिन समय इस "सरल" कार्रवाई परिवर्तित कर रहा हूँ।
मुझे इनपुट्स की तलाश है। क्या मैं यहाँ पूरी तरह से गलत हूँ?