Riutilizzo del livello della logica aziendale in più applicazioni

Question

Riutilizzo del livello della logica aziendale in più applicazioni

#1 da (2 voti)

3

Ho visto alcune persone chiedere di condividere la logica di business con più di un'applicazione e le risposte in generale discutono di metterle in una libreria di classi. Io sto bene, ma di solito gli esempi hanno due applicazioni, e fanno semplicemente una libreria di classi con la logica di business a cui entrambi si preoccupano, e entrambe le applicazioni condividono quella libreria.

Nel mio caso, ho diversi tipi di componenti (non sono sicuro se questo è il termine giusto - ad esempio, ho modem, utenti e servizi di telefonia). Ho anche diverse applicazioni, ognuna delle quali può utilizzare più tipi di componenti. Pertanto, l'applicazione A potrebbe richiedere modem e servizi di telefonia, ma non gli utenti, l'applicazione B potrebbe richiedere modem e utenti e l'applicazione C potrebbe richiedere solo i servizi di telefonia.

Sarebbe meglio avere una grande libreria di classi del livello aziendale con tutti i tipi, o dovrei avere una libreria per ogni tipo di componente?

Ad esempio, supponiamo di avere i tre componenti sopra elencati e l'accesso ai dati può essere effettuato tramite SQL Server o un'applicazione proxy.

Opzione 1: una singola libreria di classi per tutte le logiche di business nella società

MyCompany.BusinessLogic (contains business logic classes for modems, agents, telephony, ...)
MyCompany.Data.SQLServer (contains classes for accessing modem, agent, telephony data from SQL Server)
MyCompany.Data.Proxy (contains classes for accessing modem, agent, telephony data from the proxy application)
Modems.Communication (contains classes that know the protocol for communicating with a modem)
Telephony.Communication (contains classes that know the protocol for communicating with a telephony server)

Il lato negativo di questo è ogni volta che c'è una modifica alla logica o ai dati del modem, dobbiamo ricostruire e distribuire una libreria utilizzata da applicazioni che non si preoccupano nemmeno dei modem.

Opzione 2: ogni componente nella propria libreria di classi

Modems.BusinessLogic
Modems.Data.SQLServer
Modems.Data.Proxy
Modems.Communication
Agents.BusinessLogic
Agents.Data.SQLServer
Agents.Data.Proxy
Telephony.BusinessLogic
Telephony.Communication
Telephony.Data.SQLServer
Telephony.Data.Proxy

In questo modo, le applicazioni possono scegliere e scegliere le librerie che vogliono. E se uno cambia, solo le applicazioni che si preoccupano di quel tipo di componente dovrebbero cambiare. Mi preoccupo, però, di dover mantenere troppe piccole librerie. La libreria Modems.Data.SQLServer, ad esempio, potrebbe avere solo una classe in essa.

Quindi, quale metodo è più comunemente usato? O c'è un altro modo che mi manca?

architecture .net onion-architecture

posta Rob L 04.09.2018 - 22:32

fonte

1 risposta

Leggi altre domande sui tag architecture .net onion-architecture

Ottenere una visione coerente dello stato dei dati Perché DDD non considera i documenti?

score 2 · Accepted Answer

Nella mia esperienza, se hai un caso d'uso in cui vuoi selezionare diverse aree del tuo codice per il riutilizzo, come mostrato nel tuo esempio, è preferibile avere componenti piccoli e indipendenti, anche se alcuni di essi potrebbero contenere solo una classe. Hai già menzionato una buona ragione per questo nel tuo testo: limitare gli impatti del cambiamento.

Tuttavia, ci sono alcune cose da considerare:

se alcuni componenti sono strettamente accoppiati l'uno con l'altro, quindi in realtà non puoi riutilizzarne uno senza l'altro, quindi metterli in librerie diverse può diventare controproducente
aumenterà lo sforzo richiesto per la gestione della configurazione. Ciò include cose come l'impostazione di progetti, la gestione di numeri di versione, l'imballaggio, la documentazione, ecc. Questo può essere mitigato dall'avere degli standard nel progetto e automatizzare le cose, ad esempio creando script
a seconda del linguaggio di programmazione e dell'ambiente, avere molti componenti diversi può aumentare i tempi di compilazione. Nell'ambiente .Net, nella mia esperienza, questo in genere inizia ad accadere quando si hanno più di 70 o 100 librerie diverse da includere come progetti (ma non come assembly precompilati, quel numero è molto più alto). Questa documentazione per NDepend illustra il problema e fornisce alcuni suggerimenti su come affrontarlo.
per singole classi autonome, può essere sufficiente per riutilizzale tramite linkage diretto , come componenti leggeri, invece di creare una vera e propria libreria di classi intorno a loro.

Quindi, alla fine, è un trade-off: molte piccole librerie indipendenti possono essere utili, ma non le ottieni gratis. Dovrai scoprire da solo dove si trova il punto giusto per il tuo tipo specifico di progetti.