Servizio di posta elettronica o semplicemente e-mail astratta e chiamata da?

Fondamentalmente, hai due problemi qui:

• Le e-mail vengono inviate dal livello di presentazione,
• L'API è legata all'implementazione fisica della posta elettronica.

Il primo problema è risolto dalla prima fase di spostamento del codice a cui appartiene: nel livello aziendale. Non dovresti salvare le aziende dal livello di presentazione e non dovresti inviare e-mail da lì: sposta tutto il codice a cui appartiene e focalizza il livello di presentazione sulla presentazione, cioè generazione di codice HTML o JSON o XML da un modello .

Livello aziendale:

public class Example
{
    public void ProcessSamplePage(...)
    {
        CustomerManagement.Create(...);
        SmtpService.NotifyCustomerRegistered(...);
        var model = ...
        Presentation.GenerateHtml(model);
    }
}

Il passaggio da ASP.NET a ASP.NET MVC può aiutare a evitare tali errori in futuro.

Il passo successivo è Dependency Injection, che risolve anche il secondo problema. Invece di utilizzare una classe specifica fornita da .NET Framework per inviare e-mail direttamente dal tuo livello aziendale, puoi creare un'interfaccia che avrà un metodo specifico per inviare messaggi e quindi utilizzare qualsiasi implementazione tu volere. Il messaggio di spedizione può significare l'invio di una vera e-mail tramite .NET Framework, l'invio di un'e-mail attraverso una libreria di terze parti, l'invio di una e-mail mediante la connessione manuale al server SMTP, la memorizzazione di un file di testo in una directory in cui il servizio SMTP lo selezionerà o ... memorizzerà il messaggio nel database.

Livello aziendale:

public class Example
{
    public Example(IMessagesDispatcher dispatcher) { ... }

    public void ProcessSamplePage(...)
    {
        CustomerManagement.Create(...);
        this.dispatcher.NotifyCustomerRegistered(...);
        var model = ...
        Presentation.GenerateHtml(model);
    }
}

Ora che è possibile archiviare i messaggi nel database invece di inviarli semplicemente tramite e-mail, è possibile immaginare scenari più complessi, come un servizio Windows che verifica regolarmente il database e invia e-mail in sospeso. Ciò consente anche di controllare il carico del server SMTP: se si devono inviare centinaia di e-mail al secondo tra le 14:00 e le 15:00, ma solo poche decine di e-mail al minuto durante la notte, è possibile riprogrammare la priorità bassa e -Mail per essere effettivamente spedito durante la notte.

A seconda della configurazione, l'e-mail può a volte richiedere una quantità irragionevole di tempo per rispondere, e può fallire in modo ambiguo e richiedere ulteriori tentativi. Quindi suggerirei che questa è una delle volte in cui un servizio è in ordine. O sotto forma di un tuo servizio o di un server SMTP su cui hai il controllo.

Il server SMTP locale presenta un'interfaccia più nota, che media gli altri problemi, ma generalmente preferisco la situazione in cui lo stato del database è ciò che causa l'invio di messaggi in modo asincrono.

La soluzione migliore che ho visto è che l'e-mail sia integrata in un servizio di flusso di lavoro che tenga traccia di chi ha fatto cosa e chi abilita a fare ciò che segue. Quindi puoi inviare e-mail con link efficaci al loro interno, ma sapere quando quei collegamenti non sono più applicabili.