È corretto iniettare la configurazione sul livello della logica aziendale?

Question

È corretto iniettare la configurazione sul livello della logica aziendale?

#1 da (2 voti)
#2 da (0 voti)

0

Ho un'applicazione ASP.NET Core 1.1 che utilizza l'integrazione delle dipendenze ed è suddivisa in 3 livelli (web, business logic e accesso ai dati).

Vorrei accedere ad alcuni valori del file di configurazione in alcuni metodi del livello della logica aziendale. In quale modo sarebbe più corretto mantenere un'architettura pulita?

Passa i valori di configurazione come parametri-metodo mentre chiami il metodo nel livello web
Passa / inserisce la configurazione come parametro costruttore nella classe del mio livello logico aziendale

dependency-injection n-tier asp.net-core

posta Dario 22.02.2018 - 10:53

fonte

2 risposte

Leggi altre domande sui tag dependency-injection n-tier asp.net-core

Esiste un approccio migliore per l'elaborazione dei bilanci di massa Membro Value Objects utilizzato per convalidare un altro oggetto valore

score 2 · Answer 1

In qualsiasi situazione in cui le informazioni debbano essere inserite in una parte di un'app, ricorda il principio "tell, do not ask".

Se passi la configurazione direttamente nel livello della business logic, allora stai creando un accoppiamento tra i due. Diventa difficile modificare la configurazione senza rompere il livello della logica aziendale. Inoltre, è possibile creare la necessità di dover simulare la configurazione a scopo di test.

Tuttavia, dovendo passare i singoli valori di configurazione come parametri in ogni chiamata di metodo del livello aziendale dal livello web, si creano altri problemi. Aggiunge ulteriore complessità a tali firme e cerimonie di metodo per utilizzarli e richiede inoltre di esporre tutta la configurazione a tutto il livello web. Ancora una volta, ricorda "tell, do not ask": le parti del livello web dovrebbero essere informate solo su quegli aspetti della configurazione di cui hanno bisogno di sapere.

Quindi suggerirei un terzo approccio. Inietta i valori di configurazione richiesti da ogni classe all'interno del livello della logica aziendale, come parametri per i loro costruttori. In questo modo diventa responsabilità del tuo framework IoC, se ne stai utilizzando uno (o il tuo codice di mapping delle dipendenze all'avvio dell'app se stai utilizzando puro DI) per instradare i singoli valori solo per quelle classi che ne hanno bisogno.

score 0 · Answer 2

Puoi dichiarare la configurazione per modulo e averla fornita / iniettata al momento della creazione:

package: Accounts
   + AccountService
   + // internal classes
   + AccountConfig
package: Users
   + UserService
   + // internal classes
   + UserConfig
package: Config
   + IConfigProvider
   + XMLConfigProvider
   + RemoteConfigProvider

Consenti a ogni modulo di dichiarare un'interfaccia (con getter per i valori di configurazione), per i propri dati di configurazione. L'implementazione di questa interfaccia deve essere passata a ciascun modulo durante l'inizializzazione / costruzione. Puoi ulteriormente suddividere l'interfaccia di configurazione del modulo per una mappatura più fine.

Ora implementate un provider di configurazione che fornisce implementazioni per ciascuna di tali interfacce quando richiesto. Il provider potrebbe analizzare i valori effettivi da un file JSON / XML o da altre fonti.

Quando aggiungi un altro valore di configurazione a qualsiasi interfaccia di configurazione, l'interfaccia e le implementazioni del provider devono essere aggiornate.