Il nostro progetto corrente ha avuto un problema di dipendenza circolare. Il nostro assembly di business logic utilizza classi e metodi statici dal nostro assembly SharedLibrary. SharedLibrary contiene una serie di funzioni di supporto, come una classe di SQL Reader, Enumeratori, variabili globali, gestione degli errori, registrazione e convalida.Soluzione di dipendenza circolare
SharedLibrary deve accedere agli oggetti Business, ma gli oggetti Business devono accedere a SharedLibrary. I vecchi sviluppatori hanno risolto questo ovvio odore di codice replicando la funzionalità degli oggetti di business nella libreria condivisa (molto anti-DRY). Ho passato un giorno a cercare di leggere le mie opzioni per risolvere questo problema, ma sto colpendo un vicolo cieco.
Sono aperto all'idea di riprogettazione dell'architettura, ma solo come ultima risorsa. Quindi, come posso avere una libreria di helper condivisa che possa accedere agli oggetti di business, con gli oggetti business che ancora accedono alla libreria di helper condivisa?
la domanda ovvia è: perché la libreria condivisa bisogno di accedere ai business Objects? Se puoi rispondere, avrai una soluzione. – Aaronaught
SharedLibrary ha una classe di variabile globale astratta riempita con proprietà statiche. Queste proprietà vengono create dai valori del database e quindi dalla necessità di oggetti business, questo è solo un esempio di molti. E naturalmente gli oggetti Business hanno bisogno di accedere a quelle costanti. – gfoley
Ecco perché non uso mai termini vaghi come "condivisi" per descrivere una libreria. Cosa fa in realtà? Ciò che chiami una biblioteca condivisa ha chiaramente troppe responsabilità, e forse anche la libreria degli oggetti business. In genere, queste soluzioni vengono risolte inserendo le classi/interfacce veramente * indipendenti * nella propria libreria. – Aaronaught