disgiungere la logica aziendale dalla logica di supporto

1

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:

  1. sostiene la suddetta argomentazione? Se no, allora perché?
  2. vale la pena risolvere questo problema? Se no, allora perché?
  3. se è così, è stato risolto?
  4. 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

    
posta bsapaka 08.11.2018 - 01:25
fonte

0 risposte