"Non attraversare i flussi" Oggetti di accesso al database indipendenti dal livello dati in un'architettura N-Tier?

È corretto che l'iniezione di dipendenza risolva questo problema in modo pulito. Tuttavia non è necessario sapere necessariamente che cos'è o disporre di un framework per risolvere questo problema.

Ciò di cui hai bisogno è un modo per registrare un'implementazione di INotify come un'implementazione disponibile da utilizzare. (Registra dove, dici? Dico "da qualche parte, ovunque, qualunque cosa abbia senso".) E un modo per dire "Datemi l'implementazione X, per favore". Quindi ora puoi avere una classe nel DAL che si registra come implementazione DBNotify di INotify. E un'altra classe nel livello Model può richiedere il servizio di ricerca per l'implementazione DBNotify e restituire tale implementazione. Ora il livello Model non ha bisogno di sapere che DBNotify è stato implementato sul layer DAL. Naturalmente qualsiasi classe che voglia utilizzare effettivamente tali classi Model dovrà caricare DBNotify, perché il proprio livello Model non sa da dove proviene l'implementazione. Questo non è un limite particolarmente brutto, ma è quello che le classi che usano i tuoi modelli devono sapere. Hai evitato di avere una dipendenza esplicita all'interno del tuo livello del modello, ma al costo di divulgare le informazioni sulla dipendenza a tutte le classi DAL che potrebbero voler utilizzare tali classi del modello.

È qui che entra in gioco un'infrastruttura per le dipendenze. Il framework delle dipendenze è responsabile di essere il luogo in cui vengono registrate e trovate le implementazioni concrete. Meglio ancora, le informazioni su quali classi forniscono cosa, e quali altre classi hanno bisogno di cosa, di solito viene spostato in una sorta di file di configurazione. Quindi il framework dell'iniezione delle dipendenze si conclude con la responsabilità di dire, Questo tipo di oggetto ha bisogno di quel tipo di INotify, quindi ecco cosa deve essere caricato ed ecco come metterli insieme. E ora il la dipendenza non è visibile nel tuo modello e non deve essere divulgata ad altre classi DAL. Ma la stessa struttura per le dipendenze si finisce per essere una dipendenza per ogni cosa.

Quindi dovresti lanciare la tua soluzione o usare un'infrastruttura per le dipendenze? La mia opinione personale è che se si impara il framework, si desidera ammortizzare lo sforzo su tutto il codice possibile. Quindi, se disponi di un numero di luoghi che possono beneficiare di questa funzione, utilizza il framework e pianifica di iniziare a utilizzarlo in molti punti del codice. Ma se non hai altri luoghi che lo utilizzeranno, allora il tuo rolling, con la brutta dipendenza, non è un approccio orrendo.

Tuttavia, se la vedi come un'opportunità per imparare l'iniezione di dipendenza, non ti lagnerei per averlo usato. Anche se in seguito decidi di non usarlo molto.

Hmm, il tuo INotify è a livello di modello, ma la funzionalità necessaria per una particolare implementazione di essa è in un livello più in alto. Non c'è nulla che ti impedisca di creare una classe che implementa le interfacce del tuo sistema di notifica in quel livello (DAL o anche BAL) pur avendo la meccanica dichiarata nel livello del modello. Basta stare attenti a non trascinare le cose a monte (Principio di sostituzione di Liskov).

Quindi, per attivarlo, è possibile utilizzare una sorta di factory per creare un'istanza dell'implementazione necessaria al livello corretto, che viene quindi interpretata come un semplice notificatore. Realizzare questo framework di iniezione è davvero un buon modo per andare, specialmente se la configurazione, una volta impostata, non è dinamica. Ciò detto, la maggior parte può anche occuparsi della riconfigurazione dinamica, è solo un po 'più di lavoro.

Spero di aver capito bene il tuo problema e questo mi aiuta. Se esco nei campi, modifica e la domanda vedrò se riesco a dargli un altro tentativo.