Interfacce tra più progetti

Naviga le tue risposte
0

Sono leggermente confuso su quanto segue: 

ProjectA 
-------- GetUsers (Implements IDBConnector)
-------- IGetUsers
-------- UserModel

ProjectB 
-------- Main

Ho due progetti un progetto principale (progetto B) e un altro che ottiene i dati da un database (progetto A). Il progetto A ha un'interfaccia che la classe principale utilizza. La classe GetUsers viene quindi inserita nella classe principale di tipo IGetUsers.

Questo significa che esiste una dipendenza del Progetto A per il Progetto B poiché il Progetto B deve sapere come viene definita l'interfaccia e la definizione della classe stessa. Sto bene con questo dal punto di vista del codice, ma non posso fare a meno di pensare che l'interfaccia debba essere mantenuta da qualche altra parte in quanto è essenzialmente un contratto e sto cercando di seguire il principio aperto / chiuso, cioè non dovrei toccare il classe principale per modificare il modo in cui viene gestita l'interazione del database. Nel mio esempio, tuttavia, se rimuovo il progetto A, perdo la definizione dell'interfaccia e dovrei modificare la classe Main.

Avrei pensato che il Progetto B sarebbe un buon posto per mantenere l'interfaccia, ma questo risulterebbe in un riferimento circolare poiché il Progetto A avrebbe bisogno di fare riferimento al Progetto A per la dichiarazione dell'interfaccia e viceversa per l'implementazione della classe.

L'altra opzione è di avere un progetto separato per le interfacce che ho visto menzionato in questa domanda:

Condivisione di classi o interfacce tra diversi progetti

Ma a me sembra un po 'sciocco avere questa interfaccia di esempio in un intero progetto separato mentre c'è solo un'interfaccia al momento.

    
posta Simon Nicholls 09.12.2014 - 23:16
fonte

1 risposta

1

Quasi hai risposto qui:

I would have thought that Project B would be a good place to keep the interface but this would result in a circular reference ...

Seguendo il principio di inversione delle dipendenze, le interfacce dovrebbero essere definite dall'utente, non dall'implementatore. Come hai detto nella tua domanda, l'interfaccia è essenzialmente un contratto; per invertire la dipendenza, l'utente deve definire il contratto, in modo che l'implementatore dipenda da esso. Ciò contrasta con il normale flusso di dipendenza, in cui l'utente dipende dal contratto che è imposto dall'implementazione.

Quindi, tornando all'organizzazione dei progetti separati: Se B è l'utente dell'interfaccia IGetUsers , allora deve essere quello per definirlo. Se A fornisce un'implementazione di tale interfaccia, allora deve dipendere da B . E ora, non solo per evitare riferimenti circolari, ma anche per liberare B da eventuali dipendenze future che potrebbero venire, puoi definire un terzo progetto , C , che ha la sola responsabilità di componendo il sistema dai piccoli pezzi modulari.

Questo concetto è noto come composizione root , ed è idealmente il luogo in cui dovrebbe vivere tutta l'iniezione di dipendenza, lasciando A e B al di fuori dei limiti di un framework di iniezione delle dipendenze, di cui uno dovrebbe usarlo.

    
risposta data 09.12.2014 - 23:32
fonte

Leggi altre domande sui tag

Come evitare di ri-implementare le regole aziendali negli strumenti di Business Intelligence Sviluppa la GUI e la logica in una squadra nel modo giusto? [chiuso]