Unity, ad esempio, è indicato come contenitore dell'iniezione di dipendenza

link

Microsoft riprova correttamente, ecco perché non dovresti mai usare java.

Penso che sarebbe giusto dire che un contenitore DI è, almeno in parte, l'implementazione dei modelli che elenchi.

Dire che ho una classe impostata per avere un servizio iniettato

class myClass
{
    myClass(IService s)
}

Posso, e probabilmente, nella maggior parte dei casi, istanziarlo semplicemente 'manualmente' nel codice

main(string[] args)
{
    var m = new myClass(service);
}

Tuttavia. Se lavoro in un framework di qualche tipo, spesso non codifico la struttura di basso livello dell'app. Solo viste, ViewModels, Controllers, Behaviors o altri tipi di oggetti che il framework stesso istanzia in base alle necessità.

In questo caso non ho la possibilità di codificare quell'istanza. Invece ho bisogno di fornire il framework con alcuni metodi di fabbrica, in modo che quando crea le mie classi possa iniettare tutto ciò che è richiesto.

Invece di codificare manualmente una factory per ogni classe, posso usare reflection per creare uno factory generico in grado di creare qualsiasi classe. Questo è l'oggetto contenitore IoC o DI.

Un contenitore IoC / DI è un framework per la gestione delle dipendenze di un'applicazione. Poiché è un framework, dovrebbe definire un modo di creare e caricare / iniettare dipendenze particolari quando e dove richiesto. Quindi la parte

1) Creation of container

Creating a dependency container or IOC container does not require any of these design patterns(mentioned above)...

non è giusto di per sé, dal momento che ti stai riferendo a una creazione di un oggetto mentre un framework descrive un modo per raggiungere un determinato obiettivo, cioè i passaggi, i modelli di progettazione e i meccanismi.

L'uso del meccanismo di iniezione delle dipendenze, infatti, rende più appropriato il termine contenitore per l'iniezione delle dipendenze , quindi sarei d'accordo con il tuo secondo pensiero. L'iniezione di dipendenza è un meccanismo di trasmissione per ottenere IoC e inversione di dipendenza .

Per ulteriori approfondimenti e una migliore comprensione ti suggerisco di dare un'occhiata ai link sottostanti:

1. Differenza tra "Inversion of Control", "Dependency inversion "E" Disaccoppiamento "
2. Che cos'è il contenitore IoC o il contenitore DI
3. Comprensione dell'inversione del controllo, dell'iniezione delle dipendenze e del servizio Locator

1) For this line of code ApplicationContext appContext = new ClassPathXmlApplicationContext("Springbeans.xml") that creates a dependency container, Is it right to say that, creation of container has nothing to do with design pattern(like DI or SLP)?

Questa cosa è un localizzatore di servizi. Ma il modello anti con i localizzatori di servizi è di diffonderli. Tieni questo solo nella tua composizione root (tipicamente principale) e va bene.

2) Why appContext is not called a dependency container? Instead, why appContext is called IOC container?

Il CIO dipende dal polimorfismo. Ciò richiede di non sapere esattamente a cosa stai parlando. Questo si sta compiendo obbligando a separare il codice di costruzione dal codice di comportamento nel modo più estremo possibile. Realizzando la costruzione avviene in una lingua diversa (tipicamente xml). Quella separazione mantiene il codice usando dal sapere esattamente a cosa sta parlando.

Potrei scaricare un sacco di cose da cui dipendono in un insieme e chiamarlo contenitore delle dipendenze. Probabilmente volevano un nome che indicava che avevano fatto più lavoro di quello.