Per evitare che le funzioni logiche di business siano sovraccariche di logica di supporto * di problemi condivisi (ad esempio autenticazione, autorizzazione, registrazione, profilazione, limitazione della velocità di ingresso) molti framework di backend consentono di inserire la logica di supporto in middleware / interceptor.
Esempi: Express , Primavera , Rails , Flask , Lavaravel , Gin
Il middleware determina la logica di supporto, ma al costo di collegare la logica al trasporto http. Se l'app ha altri I / O come comandi CLI o gRPC, è necessario un ulteriore lavoro per applicare la logica di supporto a tali supporti. Quindi, n numero di media I / O richiederà n implementazioni di middleware.
Sto sostenendo che la logica di supporto dovrebbe essere il più indipendente possibile sia dalla logica aziendale sia dall'I / O, e che l'approccio migliore è quello di intercettare le invocazioni della logica aziendale. Non intercettare la richiesta HTTP; intercettare la chiamata alla funzione di business logic, in modo da implementare gli intercettori una volta indipendentemente dal numero di mezzi I / O.
Quindi penso che sia i middleware (non http) che i decoratori possono risolvere questo problema, ma prima di impegnarmi, chiedo:
- sostiene la suddetta argomentazione? Se no, allora perché?
- vale la pena risolvere questo problema? Se no, allora perché?
- se è così, è stato risolto?
- Se è così, per favore indicami la giusta direzione. In caso contrario, cosa consiglia?
* se esiste un termine migliore di "logica di supporto", fai clic su nei commenti