Organizzazione di messaggi umani specifici nel codice dell'applicazione Web

0

L'applicazione web Python (Flask) ha una grande porzione di messaggi email / SMS generati da modelli, tradotti da Flask-Babel.

A mio avviso, avere costanti letterali per il messaggio nelle viste, tra le altre logiche di visualizzazione e chiamate agli altri livelli, non è elegante: le viste sono lì per rendere l'html o per servire chiamate ajax, non per rendere la posta / SMS al contemporaneamente. I letterali dei messaggi nei modelli sembrano ancora più brutti, sebbene possano sembrare appartenere a loro.

Tuttavia, l'alternativa di estrapolare funzionalità relative ai messaggi in qualche altro modulo o pacchetto può sembrare troppo artificiale, perché rende più difficile comporre il messaggio, potrebbe essere necessario includere molti parametri negli alls, rendendo firme ingestibili. L'approccio di emissione / gestione degli eventi è solo una variazione di questo (non sono sicuro che possa essere buono?).

Quale potrebbe essere un buon modo per mantenere pulito il codice della vista e allo stesso tempo non rendere la distinzione troppo artificiale?

Per un semplice esempio, il form-controller potrebbe aver bisogno di inviare un messaggio di conferma (o anche più di uno) nel caso in cui il modulo sia validato e i dati ricevuti e memorizzati nel database. Ci possono essere molti dettagli coinvolti (nomi, date, bandiere, ecc.) Nel rendering dei messaggi. Come può essere fatto elegantemente?

Personalmente, penso che avere un pacchetto separato solo per la messaggistica sia abbastanza simile all'applicazione web di strata view-templates. E potrebbe anche avere vantaggi nella testabilità. Meno sicuro sull'utilizzo dei meccanismi degli eventi per far sì che i messaggi vengano inviati. Forse, mi manca qualcosa di ovvio già inventato?

    
posta Roman Susi 16.09.2017 - 19:54
fonte

2 risposte

1

Nel pattern MVC (sul lato server), la parte View è responsabile per ottenere la rappresentazione del modello all'utente. Questo può assumere molte forme, come una pagina HTML che può essere visualizzata dal browser, o un documento JSON che un'app mobile può interpretare o persino un messaggio di posta elettronica o SMS.

Hai ragione nel dire che una singola classe View non dovrebbe fare tutte queste cose, ma una singola azione in un controller è consentita per attivare gli aggiornamenti a più classi View.
Pertanto, potresti avere un set di classi View per le pagine HTML, un secondo set per il JSON e un terzo e un quarto set per i messaggi e-mail e SMS.

Inoltre, in MVC non vi è alcun divieto per una visualizzazione di spingere il suo contenuto all'utente, purché tu sappia come raggiungere l'utente.

    
risposta data 17.09.2017 - 11:00
fonte
0

Durante le ricerche di più, ho trovato il seguente articolo, affrontando quasi esattamente la mia domanda (a giudicare dagli esempi):

link

Alcuni momenti chiave:

I framework web come Flask usano qualcosa, che può essere chiamato MTV (modello, template, view, quest'ultimo può essere inteso come "controller"). (vedi laso link ). Anche se utile in casi semplici, la necessità di inviare posta / SMS (è usata come esempio nell'articolo, BTW) e simili situazioni non banali richiedono l'aggiunta di un altro livello all'architettura, il livello chiamato azioni. È dove risiede lo script di transazione che causa la messaggistica e, in pratica, dove devono poggiare le regole aziendali (il livello del modello è principalmente per la persistenza, sebbene alcune regole aziendali possano andare lì quando sono correlate a singoli aggregati di entità).

In parole semplici, significa actions pacchetto e services per accedere a servizi esterni. Quindi, fondamentalmente nel mio setup mi manca la funzionalità actions layer.

    
risposta data 18.09.2017 - 06:34
fonte

Leggi altre domande sui tag