Il problema della gestione delle dipendenze

Question

Il problema della gestione delle dipendenze

#1 da (3 voti)

1

Consideriamo la prossima situazione:

Abbiamo un modulo A che ha una classe Crt570 destinata a interagire con un dispositivo.
Abbiamo un modulo B che usa Crt570 nella classe chiamata M100Communicator.
Abbiamo due applicazioni C e D e entrambe vogliono utilizzare il modulo B.
L'applicazione D vuole usare B, ma non vuole usare Crt570 e il modulo di riferimento A, quindi.

"Modulo" qui significa dll.

Quindi abbiamo deciso di estrarre un'interfaccia da Crt570 e denominarla ICrt570. Ma cosa fare adesso? È molto strano spostare ICrt570 nel modulo di dominio (chiamiamolo modulo E) o altrove perché dopo che Crt570 deve fare riferimento al modulo che conterrà ICrt570!

Come risolvere il puzzle?

Aggiorna Per rendere la domanda più chiara per i lettori in futuro, aggiungerò un po 'più dettagli.

Il modulo A è la DLL che non contiene nient'altro che la classe Crt570 (con la sua infrastruttura). Quindi questa dll è dedicata alla gestione di un dispositivo assolutamente, niente di più.

Il modulo B è la DLL che contiene modelli specifici per diverse applicazioni nel nostro dominio. Almeno 3 applicazioni vogliono utilizzare questo modulo e, naturalmente, non vogliono estrarre le DLL di cui non hanno bisogno.

Uno dei modelli che le app C e D vogliono utilizzare è il modello M100Communicator. E, in particolare, questa classe (M100Communicator) dipende dal modulo A (classe Crt570).

Il modulo E di cui ho parlato è un modulo di dominio. Contiene molte classi e interfacce, quindi il modulo A non vuole usarlo, apparentemente.

c# architecture .net enterprise-architecture

posta EngineerSpock 12.04.2014 - 11:41

fonte

1 risposta

Leggi altre domande sui tag c# architecture .net enterprise-architecture

Come può essere ottimizzato il seguente algoritmo? DDD - Regola aziendale che dipende da un servizio

score 3 · Accepted Answer

Come scrive david.pfx nel suo commento, mancano alcune informazioni, ma sono disposto a dargli una possibilità.

Sto facendo una supposizione nella mia risposta.

Il motivo per cui C e D entrambi vogliono usare B è, almeno in parte, usare M100Communicator

Da quel momento in poi dipende se ci sono altri moduli che vogliono usare l'interfaccia ICrt570 .

Scenario A

Se è solo il modulo B che deve interagire con la tua interfaccia, puoi definirlo lì. Quindi i due C e D , potrebbero dare M100Communicator a ciascuna implementazione di ICrt570 .

C Riferimenti A and B Attribuzione di Crt570 from A a M100Communicator come implementazione di ICrt570 da utilizzare. (A dovrebbe anche fare riferimento a B dal momento che sta implementando un'interfaccia definita lì)
D Referenze solo B . Poiché M100Communicator ha bisogno di un'implementazione ICrt570 , deve ancora fornire questo. O deve fare un'implementazione stessa o fare riferimento a un altro modulo con un'implementazione.

Scenario B

Se, invece, altri moduli di B avranno una dipendenza su ICrt570 , allora avresti bisogno di spostarlo su un altro modulo, forse addirittura sul suo.

Potresti definire il modulo E mentre menzioni, contenente ICrt570 . La ragione di vita di questo modulo è il "Modulo di interfaccia di comunicazione del dispositivo". Questo modulo definisce le interfacce, nient'altro.

Quindi tutti gli altri possono fare riferimento a questo modulo: A per implementare l'interfaccia, B per avere una dipendenza su di esso. C and D in modo che sappiano cos'è ICrt570 . Poiché questo modulo è solo interfacce, non vi è molto "danno" nel farvi riferimento.

C e D sono ora liberi di scegliere qualsiasi implementazione di ICrt570 che desiderano. Lo stesso vale per X, Y, Z che usano anche ICrt570 in qualche modo.

Un paio di punti

I riferimenti non sono necessariamente negativi, solo se i moduli di riferimento hanno un sacco di cose diverse che non vuoi. Quindi potresti avere un problema con The Single Responsibility Principle , i tuoi moduli potrebbero fare troppo.
Qualcosa che mi ha aiutato a capire meglio la gestione delle dipendenze con un basso accoppiamento, è stato quello di studiare la cipolla Architettura di Jeffrey Palermo. Prende il tutto molto lontano, qualcuno potrebbe dire troppo lontano. Ma i principi del basso accoppiamento, dell'iniezione di dipendenza ecc. Sono spiegati molto bene nei suoi post sul blog.