DDD / SOA in (.NET) MVC e modello / i di messaggio / Risposta richiesta

Question

DDD / SOA in (.NET) MVC e modello / i di messaggio / Risposta richiesta

#1 da (1 voti)

2

Al momento stiamo valutando se abbia senso (o se i benefici valgano il codice aggiunto) per introdurre un modello basato sul messaggio (come la risposta alla richiesta) in un'architettura orientata al servizio / orientata ai domini sotto un'app MVC (con DI e potenzialmente usati da MVC, WCF, Windows Services, ecc.)

Fondamentalmente (in MVC) il controller usa un servizio iniettato che a sua volta usa un repository iniettato per salvare / aggiornare / eliminare oggetti.

Esistono servizi applicativi e servizi di dominio e il servizio applicativo potrebbe utilizzare più servizi di dominio, ad es. salva qualcosa e quindi invia un'email relativa all'elemento salvato.

Considerando il example use case in cui qualcosa è stato salvato e quindi viene inviata una email, potrebbe essere utile presentare all'utente potenziali errori come "Salva riuscito, ma non è stato possibile inviare l'e-mail. di nuovo in 5 minuti o contattare il supporto ecc. " vs solo un errore generico come "Salva o e-mail non ha avuto successo".

Il modello basato sul messaggio con gli oggetti Request e Response sembra soddisfacente (in teoria), o almeno gli oggetti risposta con ad es. un paio di campi ereditati potrebbe essere utile.

public abstract class ResponseBase
{
    public bool Success { get; set; }
    public string Message { get; set; }
}

Quindi potrebbe esserci un oggetto per estenderlo con il risultato ViewModel come una proprietà e infine il controller potrebbe decidere se mostrare ad es. un messaggio di errore o aggiorna la vista ecc.

Questo sembra carino, ma in simple cases in cui stai semplicemente salvando un elemento ed è chiaro che il salvataggio è riuscito o non è riuscito, può anche sembrare eccessivo. Creare e passare oggetti extra dove forse hai solo bisogno di un ID e un booleano sembra rendere questo schema ridondante. Il fatto è che questo oggetto deve essere trasferito dal controller, attraverso i servizi, al repository e viceversa. La parte richiesta potrebbe essere ignorata e si preoccupa solo di restituire un risultato significativo.

È difficile stimare se potrebbe essere 50-50 o 40-60 dove questo tipo di sistema potrebbe essere utile, ma ci sono molti casi che potrebbero usarlo, così come molti che non sono molto utili.

Esistono approcci migliori a questo problema o hai trovato questo schema utile per lo scenario ritratto? Vale la pena codificare in più per i casi semplici (nel tuo caso / i)?

c# domain-driven-design asp.net-mvc

posta lko 27.05.2013 - 16:35

fonte

1 risposta

Leggi altre domande sui tag c# domain-driven-design asp.net-mvc

Algoritmo per l'allineamento sequenziale ciclico Come scrivere test di integrazione per una piattaforma software orientata ai componenti

score 1 · Answer 1

Un'altra opzione sarebbe quella di lanciare un'eccezione personalizzata nel tuo servizio di dominio non appena qualcosa va storto e catturarlo, preferibilmente, nel tuo generatore di modelli. In questo modo il tuo codice attuale è ancora valido, ma piuttosto di dover passare una sorta di oggetti extra solo per gestire i messaggi di errore, devi solo lanciare un'eccezione e prenderla nel posto giusto. Certo, continua a gestire tutte le eccezioni non gestite (cose che non dovrebbero accadere) nel metodo Application_Error come probabilmente fai adesso.

Ecco un esempio:

public ActionResult Deposit(DepositModel model)
{
 // Some code...

 try
 {
  var depositResult = _cardDepositService.Perform(someParmaeters);

  // Some more checks...

  // The deposit has succeeded
  return DepositSuccess(model.Amount.DepositAmount.Value);
 }
 catch (DepositAmountException ex)
 {
  this.SetPopupMessage(ErrorMsg.DepositAmountError);
  return PartialView("DepositPanel", model);
 }
}

Ci sono diversi modi per gestire gli errori nelle app MVC, sentiti libero di gestirli a modo tuo; -)

Spero che ti aiuti!