Cercando di cogliere l'idea di DI / Unity e possibilmente applicarlo alla nostra semplice applicazione

Question

Cercando di cogliere l'idea di DI / Unity e possibilmente applicarlo alla nostra semplice applicazione

#1 da (4 voti)
#2 da (1 voti)

1

In pratica, la nostra app è formata da poche forme compilate da persone .. Quindi questi moduli vengono convalidati e revisionati e vengono creati rapporti.

Quindi stavo pensando a DI e scherzando con un semplice esempio di Unity + MVC

link

Quindi potrebbe essere utile per qualcosa o eccessivo? Mi sembra che l'idea alla base di DI sia quella di afferrare dinamicamente oggetti di un tipo diverso. Quindi nel mio caso forse quelli possono essere un insieme di regole per la convalida di un modulo ... Qualcosa come SyntaxRules1.dll, BusinessRules1.dll, CalculationRules1 .dll ... Quindi, con il passare del tempo, potrebbero essere creati ulteriori set di regole in modo da poter rilasciare un'altra DLL come BusinessRules2.dll in una cartella e DI prenderlo nel boot strapper ..

Ma di nuovo, se cambia molto poco, usare DI potrebbe essere inutile e basta essere uno strato di astrazione che non è necessario ..

Ho l'idea giusta? Ci sono altre idee su come DI potrebbe essere utile per questo tipo di app? Potrei rendere l'intera vista / controller / modello o ogni modulo la sua DLL? Questo ha senso ?

Ho appena letto un sacco di teoria e sto lottando per trovare alcuni esempi concreti di ciò che può fare D.

dependency-injection ioc-containers mvc

posta punkouter2018 25.04.2012 - 20:39

fonte

2 risposte

Leggi altre domande sui tag dependency-injection ioc-containers mvc

Classe extra per scrivere dati su qualche back-end? Quale di questi sembra più pulito?

score 4 · Answer 1

It seems to me the idea behind DI is to dynamically grab objects of a different type

No, non lo è. DI sta per Iniezione di Dipendenza. L'idea è che al posto delle classi che istanziano le classi / servizi di cui hanno bisogno per funzionare, queste sono passate a loro (cioè iniettate) - questo è normalmente fatto sia sul costruttore che attraverso proprietà pubbliche.

Scrivere classi in questo modo ti permette di avere una struttura più modulare per il tuo codice e significa che l'utente di una classe (il codice chiamante) deve passare nelle dipendenze.

Questo concetto è quello di Inversion of Control (IoC), che usa DI per raggiungere questo obiettivo.

Dove entra in gioco un contenitore IoC come Unity è che ti permette di determinare in configurazione (che può essere strongmente digitata la configurazione del codice fluente) come fornire una classe con le sue dipendenze.

Ora, direi che DI è una tecnica utile in qualsiasi applicazione. Ti permette di scrivere più codice testabile e ti permette di testare il tuo codice in isolamento (cioè senza avere per disegnare nelle dipendenze). I quadri di derisione aiutano in questo senso.

Un contenitore IoC, d'altra parte, è probabilmente eccessivo per una piccola e semplice applicazione. È utile nei casi in cui si hanno catene di dipendenze o molte dipendenze nel codebase.

L'esempio che hai fornito - il richiamo delle regole dinamicamente suona come qualcosa che sarebbe meglio ottenere usando un'architettura di plugin, possibilmente usando MEF . Non è qualcosa direttamente correlato a DI o IoC.

score 1 · Answer 2

Ho fatto quello di cui stai parlando usando Unity con un leggero cambiamento nella tua percezione di Dipendenza dall'iniezione (DI). Tutti i metodi di immissione delle dipendenze implicano il passaggio di un tipo di classe istanziata nel costruttore della classe piuttosto che la creazione di istanza del tipo da parte della classe.

Come affermato in un poster precedente, questo è utile per scopi di test poiché puoi scrivere codice di prova per la tua classe e passare in tipi di istanze differenti per testare la funzionalità della classe.

Tuttavia, per fare ciò che stai chiedendo riguardo al passaggio in BLL, dovresti usare DI ma invece di passare la tua classe BLL, passeresti in un oggetto servizio / controllore che restituirebbe un BLL appropriato. Tale oggetto di servizio dovrebbe conoscere internamente quale BLL restituire in base alla funzionalità creata dall'utente. Quell'oggetto di servizio potrebbe essere un tipo di interfaccia con una funzione come getBLL (myCustomerNumber);

La parte dinamica si presenta come Inversion of Control (IOC). Quindi, in termini di IOC, dovresti registrare il tuo servizio (la classe che sa quale BLL restituire) a quel tipo di interfaccia. Pertanto, ogni volta che quel servizio viene fatto riferimento in un costruttore di classi, unity usa il servizio (classe) che è stato registrato per passare nel costruttore.

Si prega di prendere nota: Con l'unità, è possibile registrare / creare una classe / servizio con / senza un manager di vita. Questo è importante per la ricerca perché se non si dispone di un LifeTimeManager, la classe registrata verrà creata ogni volta che viene fatto riferimento. Con LifeTimeManager, verrà creato una volta nel sistema e utilizzato in tutto il sistema. Puoi volerlo in determinate circostanze e in altre persone che non puoi.