Ho iniziato a lavorare in un progetto circa 3 mesi fa e da quando mi sono iscritto ho visto tanti errori nell'intero progetto - l'architettura è completamente disfunzionale e mal implementata e molti concetti usati come Inversion of Control sono implementati in un modo che va completamente contro le convenzioni appropriate. Le persone hanno opinioni, conoscenze, esperienze diverse ed è completamente corretto per risolvere un problema utilizzando approcci diversi. Il problema è quando le cose vengono implementate in un modo molto sbagliato. Dato che ci sono così tanti problemi con il design attuale, ne descriverò uno come esempio.
Abbiamo un buon numero di componenti e ognuno è definito da un insieme di diversi progetti (stiamo usando C #) in questo modo:
- Company.Product.Repositories
- Company.Product.Repositories.Contracts
-
Company.Product.Repositories.IoC (RepositoriesIoCManager)
-
Company.Product.Services
- Company.Product.Services.Contracts
- Company.Product.Services.IoC (ServicesIoCManager)
Nel progetto IoC abbiamo un paio di programmi di installazione di windsor castle per configurare le dipendenze per quel componente specifico, quindi dato l'esempio sopra avremmo due installatori uno per ogni componente
Ora diciamo che il componente Servizi ha una dipendenza indiretta dai repository - che è una configurazione tipica - nel nostro caso il progetto Servizi ha un riferimento diretto al progetto Repository e chiama un metodo statico nel tipo RepositoryIoCManager per avviare il Programma di installazione di IoC. Questa configurazione funziona solo perché abbiamo un singolo prodotto / regione e nessun CI, e si romperebbe facilmente nel caso in cui avessimo implementazioni di repository differenti per la stessa interfaccia, non potevi semplicemente scambiare le diverse DLL durante il processo build / package / deploy tutto è referenziato staticamente.
Tra le altre cose, questo rende l'uso di IoC completamente inutile, perché non abbiamo nemmeno test unitari, quindi non c'è niente da prendere in giro.
Ho cercato di spiegare al ragazzo come si è rotto il concetto, che l'IoC è usato tra le altre cose per consentire un accoppiamento lento tra componenti, che è l'opposto che abbiamo qui, ma ogni volta che lo faccio, mi viene detto che non sono flessibilmente e quel pattern X è come qualsiasi altro pattern e non riesco a trovare altri argomenti. Cosa faresti in questo caso? creare un progetto dimostrativo e provare a far vedere alle persone quali problemi risolve IoC e come dovrebbe essere implementato correttamente o semplicemente accettare che questo è un altro modo "personalizzato" di implementare IoC?
Aggiorna
