ਡਾਟ.ਨੈੱਟ ਵਿੱਚ ਡਿਪੈਂਡੈਂਸੀ ਇਨਜੈਕਸ਼ਨ ਕਿਵੇਂ ਕੰਮ ਕਰਦੀ ਹੈ?

Question

Accepted Answer

**Dependency Injection (DI)** ਆਧੁਨਿਕ .NET ਵਿੱਚ ਬਿਲਟ-ਇਨ ਹੈ — ਫਰੇਮਵਰਕ ਵਿੱਚ ਇੱਕ DI ਕੰਟੇਨਰ ਸ਼ਾਮਲ ਹੈ ਜੋ ਸਵੈਚਲਿਤ ਤੌਰ 'ਤੇ ਕਲਾਸਾਂ ਨੂੰ ਬਣਾਉਂਦਾ ਹੈ ਅਤੇ **ਉਹਨਾਂ ਦੇ ਡਿਪੈਂਡੈਂਸੀ ਇਨਜੈਕਟ ਕਰਦਾ** ਹੈ। ਤੁਸੀਂ ਸਰਵਿਸਿਜ਼ ਨੂੰ ਰਜਿਸਟਰ ਕਰਦੇ ਹੋ (interfaces ਨੂੰ implementations ਨਾਲ ਮੈਪ ਕਰਦੇ ਹੋ) ਅਤੇ ਕੰਟੇਨਰ ਇਹਨਾਂ ਨੂੰ ਹੱਲ ਕਰਦਾ ਹੈ, ਲੂਜ਼ਲੀ-ਕਪਲਡ, ਟੈਸਟੇਬਲ ਕੋਡ ਸਮਰੱਥ ਕਰਦੇ ਹੋ। ਇਹ ASP.NET Core ਦੀ ਨੀਂਦ ਹੈ। ## ਸਰਵਿਸਿਜ਼ ਨੂੰ ਰਜਿਸਟਰ ਕਰਨਾ ```csharp // in Program.cs — register services with a LIFETIME builder.Services.AddScoped(); // interface → implementation builder.Services.AddSingleton(); builder.Services.AddTransient(); ``` ਤੁਸੀਂ ਹਰੇਕ ਸਰਵਿਸ ਮੈਪਿੰਗ ਇੱਕ **interface ਨੂੰ ਇੱਕ implementation ਨਾਲ** ਇੱਕ lifetime ਦੇ ਨਾਲ ਰਜਿਸਟਰ ਕਰਦੇ ਹੋ। ਫਿਰ ਕੋਈ ਵੀ interface 'ਤੇ ਨਿਰਭਰ ਰਜਿਸਟਰਡ implementation ਪ੍ਰਾਪਤ ਕਰਦਾ ਹੈ। ## Constructor injection (ਮਾਨਕ ਪੈਟਰਨ) ```csharp public class UserService { private readonly IUserRepository _repo; private readonly IEmailSender _email; // dependencies are declared in the constructor — the container INJECTS them automatically public UserService(IUserRepository repo, IEmailSender email) { _repo = repo; _email = email; } } // you never `new UserService(...)` manually — the container builds it, resolving the chain ``` Dependencies ਨੂੰ constructor parameters ਵਜੋਂ ਘੋਸ਼ਿਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ (interfaces ਦੇ ਰੂਪ ਵਿੱਚ ਟਾਈਪ ਕੀਤਾ); ਕੰਟੇਨਰ ਕਲਾਸ ਨੂੰ ਬਣਾਉਂਦਾ ਹੈ ਅਤੇ ਰਜਿਸਟਰਡ implementations ਨੂੰ ਇਨਜੈਕਟ ਕਰਦਾ ਹੈ, ਸਮੁੱਚੀ ਡਿਪੈਂਡੈਂਸੀ ਗ੍ਰਾਫ ਨੂੰ ਸਵੈਚਲਿਤ ਤੌਰ 'ਤੇ ਹੱਲ ਕਰਦੇ ਹੋ। ## Service lifetimes (ਸਹੀ ਤੌਰ 'ਤੇ ਚੁਣਨਾ ਮਹੱਤਵਪੂਰਨ ਹੈ) ```text Singleton → ONE instance for the entire app lifetime (shared; must be thread-safe) Scoped → one instance PER request (the common default for web — e.g. DbContext) Transient → a NEW instance every time it's requested (lightweight, stateless services) → Choosing wrong (e.g. a singleton capturing a scoped DbContext) causes subtle bugs. ``` ## ਲਾਭ: ਲੂਜ਼ ਕਪਲਿੰਗ ਅਤੇ ਟੈਸਟਬਿਲਿਟੀ ```csharp // because UserService depends on INTERFACES, you can inject MOCKS in tests var service = new UserService(mockRepo, mockEmail); // no real DB/email needed ``` ## ਇਸ ਨੂੰ ਮਹੱਤਵ ਕਿਉਂ Dependency injection ਆਧੁਨਿਕ .NET ਲਈ ਨੀਂਦ ਹੈ — ਇਹ **ਫਰੇਮਵਰਕ ਵਿੱਚ ਬਿਲਟ-ਇਨ** ਹੈ ਅਤੇ ASP.NET Core ਦੀ ਰੀੜ੍ਹ ਦੀ ਹੱਡੀ ਹੈ, ਇਸਲਈ ਇਹ ਸਮਝਣਾ ਕਿਸੇ ਵੀ ਆਧੁਨਿਕ C# ਐਪਲੀਕੇਸ਼ਨ ਡਿਵੈਲਪਮੈਂਟ ਲਈ ਜ਼ਰੂਰੀ ਹੈ। ਫਰੇਮਵਰਕ ਦਾ ਬਿਲਟ-ਇਨ DI ਕੰਟੇਨਰ ਸਵੈਚਲਿਤ ਤੌਰ 'ਤੇ ਕਲਾਸਾਂ ਨੂੰ ਬਣਾਉਂਦਾ ਹੈ ਅਤੇ ਉਹਨਾਂ ਦੇ ਡਿਪੈਂਡੈਂਸੀ ਇਨਜੈਕਟ ਕਰਦਾ ਹੈ (ਸਮੁੱਚੀ ਡਿਪੈਂਡੈਂਸੀ ਗ੍ਰਾਫ ਨੂੰ ਹੱਲ ਕਰਦਾ ਹੈ), ਇਸਲਈ ਤੁਸੀਂ ਸਰਵਿਸਿਜ਼ ਨੂੰ ਰਜਿਸਟਰ ਕਰਦੇ ਹੋ ਅਤੇ ਕੰਟੇਨਰ ਨੂੰ ਸਭ ਕੁਝ ਤਾਰ ਕਰਨ ਦਿੰਦੇ ਹੋ ਪਰ ਸਰਵਿਸਿਜ਼ ਨੂੰ ਖੁਦ ਤੁਰੰਤ ਨਹੀਂ ਕਰਦੇ ਹੋ। ਮੂਲ ਲਾਭ ਮਹੱਤਵਪੂਰਨ ਹਨ ਅਤੇ ਮਾਣਕ ਕੀ DI ਨੂੰ ਜ਼ੋਰ ਦੇਇਆ ਜਾਂਦਾ ਹੈ ਇਸ ਦਾ ਕੇਂਦਰ ਹੈ: **ਲੂਜ਼ ਕਪਲਿੰਗ** (concrete classes ਦੀ ਬਜਾਏ interfaces 'ਤੇ ਨਿਰਭਰ ਹੋਣਾ, ਤਾਂ ਕਿ implementations ਨੂੰ ਬਦਲਿਆ ਜਾ ਸਕੇ) ਅਤੇ ਖਾਸ ਤੌਰ 'ਤੇ **ਟੈਸਟਬਿਲਿਟੀ** (tests ਵਿੱਚ ਅਸਲ dependencies ਦੀ ਬਜਾਏ mock implementations ਇਨਜੈਕਟ ਕਰਨਾ ਜਿਵੇਂ ਡਾਟਾਬੇਸ ਜਾਂ ਈਮੇਲ ਸਰਵਿਸਿਜ਼ — ਮੋਟੀ ਯੂਨਿਟ ਟੈਸਟਿੰਗ ਨੂੰ ਅਭਿਆਸੀ ਬਣਾਉਂਦੇ ਹੋ)। ਸਰਵਿਸਿਜ਼ ਨੂੰ ਰਜਿਸਟਰ ਕਰਨਾ (interfaces ਨੂੰ implementations ਨਾਲ ਮੈਪ ਕਰਨਾ), constructor injection (ਮਾਨਕ ਪੈਟਰਨ), ਅਤੇ — ਮਹੱਤਵਪੂਰਨ — **service lifetimes** (`Singleton`, `Scoped`, `Transient`) ਨੂੰ ਸਮਝਣਾ ਜ਼ਰੂਰੀ ਹੈ: ਗਲਤ lifetime ਚੁਣਨਾ ਸੂਖਮ, ਸਖ਼ਤ-ਡੈਬਗ ਕਰਨ ਵਾਲੀਆਂ ਬੱਗਾਂ ਦਾ ਕਾਰਨ ਬਣਦਾ ਹੈ (ਜਿਵੇਂ ਇੱਕ singleton ਜੋ ਇੱਕ scoped `DbContext` ਰਖਦਾ ਹੈ, ਜਾਂ ਸਾਝੇ singletons ਦੇ ਨਾਲ thread-safety ਮੁੱਦੇ), ਇਸਲਈ ਇਹ ਸਮਝਣਾ ਕਿ ਹਰੇਕ lifetime ਕਦੋਂ ਲਾਗੂ ਹੁੰਦੀ ਹੈ (Scoped per-request ਹੋ ਰਿਹਾ ਹੈ DbContext ਵਰਗੀਆਂ ਚੀਜ਼ਾਂ ਲਈ, Singleton ਸਾਝੀ ਸਟੇਟਲੈੱਸ ਸਰਵਿਸਿਜ਼ ਲਈ, Transient ਲਘੂਵਾਜ ਵਾਲੀਆਂ ਲਈ) ਆਲੋਚਨਾਤਮਕ ਹੈ। ਕਿਉਂਕਿ DI .NET ਵਿੱਚ ਬਿਲਟ-ਇਨ ਹੈ, ASP.NET Core ਦੀ ਤਾਮੀਰ ਨੂੰ ਅਧਿਕਾਰ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਲੂਜ਼ਲੀ-ਕਪਲਡ, ਟੈਸਟਬਲ ਕੋਡ ਲਿਖਣ ਦੀ ਕੁੰਜੀ ਹੈ, ਵਿਸਤ੍ਰਿਤ ਗਿਆਨ ਮਹੱਤਵਪੂਰਨ ਹੈ — ਕੰਟੇਨਰ, constructor injection, interface-based ਡਿਜ਼ਾਇਨ, ਅਤੇ ਖਾਸ ਤੌਰ 'ਤੇ service lifetimes — ਆਧੁਨਿਕ C# ਐਪਲੀਕੇਸ਼ਨਾਂ ਨੂੰ ਬਣਾਉਣ, ਬਾਵਜੂਦ ਦਾ, ਟੈਸਟਬਲ ਲਈ ਮੁਹਾਰਤ ਸਮ੍ਹਾ, ਅਤੇ ਇੱਕ ਆਮ ਇੰਟਰਵਿਊ ਮੁਦਾ ਹੈ।