In che modo l'integrazione della dipendenza può essere integrata nella lingua? [chiuso]

10

Ho riflettuto un po 'su come l'integrazione delle dipendenze potrebbe essere meglio integrata direttamente in un linguaggio C #. Ho trovato una soluzione potenziale su cui vorrei sentire la tua opinione. Non ho usato molti framework per le dipendenze, quindi potrebbe esserci qualcosa che trascuro

Comunque, l'idea è di poter dichiarare le proprietà come "iniettabili" usando una parola chiave. Quando un oggetto viene istanziato e tale proprietà non viene inizializzata tramite il costruttore o l'inizializzatore dell'oggetto, richiede un'istanza di quel tipo di proprietà da qualche servizio globale.

Allo stesso modo registri i gestori per diversi tipi di quel servizio in modo da poter istanziare il tipo di proprietà iniettato.

L'aspetto positivo dell'utilizzo di questo tipo di architettura IMO è che è abbastanza flessibile e facile da usare. Il rovescio della medaglia è che potrebbe esserci un sovraccarico nel fare il richiamo al singleton ogni volta che si avvia una classe che ha un'iniezione.

Quindi di nuovo questo è solo un problema per le classi che vengono istanziate di frequente in una soluzione ad alte prestazioni, quindi non dovrebbe essere un grosso problema. Forse potresti usare una specie di fabbrica in quei casi.

Pensiero, problemi, domande, idee migliori?

Codice

public class SomeClass
{

  public SomeClass()
  {
     //implicit behavior if Animal is not set in constructor or initializer
    this.Animal =  GlobalInjector.Get(this,typeof(Mammal))

  }

  public injectable Mammal Animal  
  {
   get;
   set;
  }
}


 GlobalInjector.Register(typeof(Mammal), () => return new Mammal(someParameter));
    
posta Homde 30.03.2011 - 09:27
fonte

4 risposte

7

Ci sono cose che appartengono alle lingue e cose che non lo fanno. Molto tempo fa C ha riconosciuto che IO non apparteneva alla lingua perché è esterno al modello di calcolo e può essere implementato con le librerie di funzioni.

L'iniezione di dipendenza è così. È esterno alla lingua e può essere implementato con framework appropriati.

Uno dei problemi con le lingue moderne è che cercano di fare troppo. Alla fine quelle lingue crollano sotto il loro stesso peso, mentre i programmatori fuggono verso linguaggi più semplici.

    
risposta data 07.04.2011 - 14:06
fonte
5

Non è necessario

Una delle cose che mi piace di più dei migliori framework DI che ho usato è che il codice di configurazione di alto livello è l'unica parte del codice che deve sapere su DI. Il cablaggio automatico viene eseguito a livello di contenitore e configurazione / "caricamento del modulo" e il codice dell'applicazione può essere completamente ignaro di ciò.

Questo significa nessun attributo, nessuna stringa magica, nessuna convenzione. Ogni pezzo di codice sa solo che accetta il codice nel suo costruttore (/ proprietà / metodi), e questo è tutto.

Con un design del genere non è necessario modificare la lingua del tutto per supportare l'iniezione delle dipendenze.

È potenzialmente pericoloso

La cosa che temo di più di un sistema di iniezione delle dipendenze integrato nella lingua è che innalzerebbe una barriera contro qualsiasi altra implementazione, ma probabilmente si dipingerebbe in un angolo in qualche aspetto.

Alcuni modi in cui potrebbe dipingersi in un angolo:

  • Supporta solo la configurazione basata su XML o solo la configurazione basata su codice
  • Non essere in grado di supportare in modo pulito il modello di progettazione di fabbrica (non solo componenti transitori: componenti generati in fase di esecuzione)
  • In qualche modo, cambiando il mio codice, sono stato costretto a usare l'integrazione delle dipendenze e non potevo semplicemente istanziare la mia classe per i test delle unità
  • Non supporta i cicli di vita personalizzati
  • Non è estensibile
  • Non è sostituibile nei casi in cui ho bisogno di una maggiore personalizzazione
  • Si è rotto in qualche modo che non capiamo ancora, perché noi utenti di .Net non abbiamo usato DI abbastanza a lungo da conoscere le insidie
risposta data 17.11.2011 - 13:21
fonte
4

Hai visto il Managed Extensibility Framework fornito con .NET 4? Ecco un articolo Ho scritto con alcuni esempi. Fondamentalmente si tratta di una forma di integrazione delle dipendenze integrata in .NET, con le funzionalità aggiunte di rilevabilità in fase di esecuzione.

Le iniezioni di proprietà hanno questo aspetto:

class Program
{
    [Import]
    public IMessageSender MessageSender { get; set; }
}

Le iniezioni del costruttore hanno questo aspetto:

class Program
{
    [ImportingConstructor]
    public Program(IMessageSender messageSender) 
    {
    ...
    }
}

È possibile importare campi, importare facoltativamente, importare raccolte di servizi, inclusa l'importazione lenta con metadati in modo da poter cercare un servizio appropriato da istanziare. Puoi anche reimportare in fase di esecuzione per cercare nuove estensioni.

    
risposta data 30.03.2011 - 16:26
fonte
2
  1. In realtà non descrivi il meccanismo di configurazione, che IMHO è un po 'complicato. Come si fa a fare in modo che tutto il codice in esecuzione in un thread utilizzi la connessione DB A, e tutto il codice nell'altra connessione di thread B? Come si blocca l'inserimento di una determinata risorsa, poiché l'utente attualmente loggato non può accedervi?
  2. Non utilizzare un iniettore globale. Non utilizzare alcuna cosa globale, o si potrebbe anche usare le variabili globali. No, usare OOP-speak come singleton o "statico" anziché globale non cambia la loro natura globale.
  3. Considera un contenitore con ambito dinamico. Mentre lo scope lessicale ha giustamente vinto contro l'ambito dinamico, credo che l'ambito dinamico sarebbe un valido sostituto dell'ambito globale. L'ereditarietà differenziale sarebbe una bella implementazione (come nell'ereditarietà basata sul prototipo).
  4. Credo che un DI-meccanismo imposto dal linguaggio dovrebbe essere davvero semplice, nessuna di quelle cose di livello enterprise che è la norma in C # e Java. Potrebbe esserci un meccanismo di scoping dinamico con un semplice livello di configurazione in cima. Le soluzioni aziendali possono essere sovrapposte da terze parti.
risposta data 30.03.2011 - 15:56
fonte