Core Concepts of Dependency Injection and Services in ASP.NET Core Quiz

Explore fundamental principles of dependency injection and service lifetimes in ASP.NET Core with this beginner-friendly quiz. Improve your understanding of configuring, managing, and using services in modern application development.

1. Understanding the Purpose of Dependency Injection

   What is the main reason for using dependency injection in an ASP.NET Core application?

   1. To avoid writing unit tests
   2. To improve background image loading speed
   3. To increase physical server memory
   4. To reduce tight coupling between classes

   Explanation: Dependency injection primarily helps reduce tight coupling between classes by allowing their dependencies to be provided from the outside, thus improving flexibility and testability. Improving image loading speed and increasing server memory are unrelated to dependency injection. Avoiding unit tests is not its goal; in fact, dependency injection makes unit testing easier.

2. Recognizing Built-in Service Lifetimes

   Which service lifetime creates a new instance of the service for every HTTP request in ASP.NET Core?

   1. Scoped
   2. Manual
   3. Singleton
   4. Threaded

   Explanation: The scoped lifetime ensures one instance of the service per HTTP request, making it suitable for services that use request-specific data. Singleton uses one instance for the application's lifetime, while 'Threaded' and 'Manual' are not valid service lifetimes in this context.

3. Registering Services in the Container

   What is the correct method to register a singleton service in the dependency injection container during application startup?

   1. services.AddSingletonu003CMyServiceu003E()
   2. services.AddTransitionalu003CMyServiceu003E()
   3. services.MakeSingleu003CMyServiceu003E()
   4. container.CreateSingletonu003CMyServiceu003E()

   Explanation: Using 'services.AddSingletonu003CMyServiceu003E()' registers a singleton service correctly. The other methods are either inaccurately named ('CreateSingleton', 'MakeSingle', or 'AddTransitional') and do not exist within the standard service registration options.

4. Injecting Services into Controllers

   In an ASP.NET Core MVC controller, how do you typically receive a service instance using dependency injection?

   1. By using a global keyword
   2. Through a static class variable
   3. Through a constructor parameter
   4. With a private event handler

   Explanation: Services are injected into controllers via constructor parameters, allowing the controller to receive required dependencies at runtime. There are no 'global keywords' for injection, and static variables or event handlers are not standard for managing services by dependency injection.

5. Understanding Transient Services

   What happens each time a transient service is requested from the dependency injection system?

   1. A new instance is created
   2. Service registration is skipped
   3. A compile-time error occurs
   4. The same instance is returned

   Explanation: When a transient service is requested, a new instance is created every time, ensuring that no state is shared. Returning the same instance is characteristic of singletons. Service registration is not bypassed, and requesting a transient service does not cause a compile-time error by itself.

6. Resolving Service Dependencies Recursively

   What occurs if a service registered with dependency injection has its own dependencies?

   1. The service cannot be registered
   2. All dependencies must be static
   3. The container resolves nested dependencies automatically
   4. A stack overflow exception is always thrown

   Explanation: The dependency injection container recursively resolves dependencies, creating and injecting required instances. Stack overflows only occur with circular dependencies, not with normal nested dependencies. Services can be registered regardless of having dependencies, and static dependencies are not required.

7. Using the IServiceCollection Interface

   Which object is typically used to register services and configure dependency injection in the application startup?

   1. IServiceCollection
   2. IClassResolver
   3. ITypeActivator
   4. IMultiThreader

   Explanation: IServiceCollection is the interface provided for registering and configuring services. The others ('IClassResolver', 'IMultiThreader', 'ITypeActivator') are not used for registering services in the dependency injection setup.

8. Removing Hard-coded Dependencies

   Why is removing hard-coded dependencies important when designing services in ASP.NET Core applications?

   1. To improve code maintainability and testability
   2. To enable video streaming support
   3. To increase minification speed
   4. To decrease allowable memory size

   Explanation: By removing hard-coded dependencies, you make your code easier to maintain and test, as dependencies become interchangeable and mockable. Minification speed and memory size are unrelated, and support for video streaming is not directly affected by dependency management.

9. Recognizing Constructor Injection

   Which statement describes constructor injection in the context of dependency injection?

   1. Dependencies are set using a settings file
   2. Dependencies are passed through method return values
   3. Dependencies are supplied via parameters in a class constructor
   4. Dependencies are injected automatically as global variables

   Explanation: Constructor injection supplies service dependencies through parameters of a class constructor, enabling automatic wiring by the DI container. Passing dependencies via method return values or global variables is not standard practice, and a settings file does not inject service instances.

10. Avoiding Common Mistakes with Singleton Services

    What precaution should you take when registering a service as a singleton in ASP.NET Core?

    1. Use the Dispose pattern in every method
    2. Make all properties public by default
    3. Ensure the service is stateless or thread-safe
    4. Force garbage collection manually

    Explanation: Singleton services must be stateless or thread-safe to avoid issues with shared data across requests. Implementing the Dispose pattern in every method is unnecessary and unrelated. Making all properties public or forcing garbage collection manually do not address the essential thread safety concerns of singletons.