Separazione di preoccupazioni Servizi SOAP

Se l'utente prende la decisione diretta di inviare l'e-mail, l'app client è sicuramente il posto giusto.

Tuttavia, se come suggerisce il tuo commento, l'invio dell'email è il risultato di una serie di eventi come quando uno studente viene approvato per un corso, quindi, potrebbe avere la logica di quando "NotifyStudentOfApproval ()" nel servizio di registrazione, ma in questo caso sarebbe assolutamente racchiudere una chiamata al servizio SendEmail e non essere costruito rispetto a qualsiasi dll di SendEmail. Inoltre, la chiamata sarebbe ben congegnata in try-catch in modo che eventuali errori di invio dell'e-mail non impedissero il successo del processo di approvazione.

Tuttavia, fare questo concettualmente associa questo evento a un'e-mail all'interno del tuo servizio. Se "quando viene inviata la notifica" cambia, o qualcosa su come viene costruita la posta elettronica cambia, o se il meccanismo di comunicazione cambia (come hai ipotizzato), allora il servizio di registrazione è costretto a cambiare. Inoltre, cosa succede quando SendEmail è inattivo o restituisce un errore? Come ho già detto, non vuoi che ciò porti l'iscrizione a Hail. Ma questo significa che gli studenti non verrebbero notificati? Non mi piace niente di quello.

Quindi, in realtà, consiglierei di utilizzare la messaggistica in stile pub-sub (e affidabile) per informare un servizio separato che è avvenuta un'approvazione. Forse questo servizio è molto piccolo e monouso: NotifyStudentOfApproval (dipende da ciò che tutto il resto può essere molto simile in quella linea o responsabilità). Il servizio di iscrizione pubblicherebbe eventi come "StudentApprovedForCourse". L'altro servizio si iscriverebbe a quegli eventi e quindi prenderà l'azione necessaria per notificare lo studente in qualsiasi modo sia appropriato, come una e-mail. E chiamerebbe il servizio di posta elettronica. Pertanto, quando si verifica uno di questi scenari "se" precedenti, il servizio di registrazione non viene modificato. Le modifiche sono limitate al servizio NotifyStudentOfApproval e la distribuzione è limitata a questo. Inoltre, con la messaggistica in coda, puoi generalmente distribuire in qualsiasi momento senza preoccuparti che gli studenti non ricevano notifiche.

Rompere le cose (un po ', non troppo) come questo può davvero lenire il dolore di fare un cambiamento "qui" e di influenzare tutto. Inoltre, supponendo che la messaggistica sia accodata come dovrebbe, rende i tempi di inattività del sistema molto meno impattanti. In questo esempio, se il servizio SendEmail è inattivo per un po 'di tempo, o viene inviato NotifyStudentOfApproval, va bene. Quando viene eseguito il backup, elaboreranno tutte le notifiche di cui è stato eseguito il backup nella loro "Posta in arrivo" dei messaggi. Questo è molto meglio che far rompere le cose perché tutto dipende in ultima analisi da tutto. "Non posso approvare lo studente per il corso perché il sistema di posta elettronica non funziona." ecc.