{"@context":"https://schema.org","@type":"FAQPage","mainEntity":[{"@type":"Question","name":"What is the main issue with the Singleton pattern in modern .NET with Dependency Injection?","acceptedAnswer":{"@type":"Answer","text":"The classic Singleton pattern (static instance) conflicts with dependency injection because it creates tight coupling and makes testing difficult. In modern .NET, it's better to use the 'Singleton' service lifetime via DI (services.AddSingleton), which provides the same single-instance guarantee while enabling injection, mocking, and testability. Static Singleton bypasses the DI container and creates hidden dependencies."}},{"@type":"Question","name":"In the Factory Method pattern, what is the difference between Factory Method and Abstract Factory in .NET?","acceptedAnswer":{"@type":"Answer","text":"Factory Method defines a virtual method to create a single type of object (e.g., CreateLogger), allowing subclasses to decide which concrete class to instantiate. Abstract Factory defines an interface for creating families of related objects (e.g., IUIFactory with CreateButton, CreateTextBox), allowing multiple coherent products to be created together. Factory Method focuses on a single product with polymorphism, Abstract Factory manages multiple products from the same family."}},{"@type":"Question","name":"What is the main advantage of the Builder pattern in .NET for creating complex objects with many optional parameters?","acceptedAnswer":{"@type":"Answer","text":"The Builder pattern avoids telescoping constructors (multiple overloads with different parameter combinations) by providing a fluent interface to build the object step by step. It allows creating complex objects with optional parameters in a readable and maintainable way, unlike constructors with 10+ parameters. In modern C#, init properties and records can replace Builder for simple cases, but Builder remains useful for complex validation or multi-step construction."}},{"@type":"Question","name":"What is the Single Responsibility Principle (SRP) in SOLID and how to apply it in .NET?","acceptedAnswer":{"@type":"Answer","text":"SRP states that a class should have only one reason to change, meaning a single responsibility. In .NET, this means separating concerns: a Controller should not contain business logic (use services), a class should not handle both persistence and validation (separate into Repository and Validator). Violating SRP creates classes that are hard to test, maintain, and reuse. For example, separate UserService (business logic) and UserRepository (data access)."}},{"@type":"Question","name":"What is the Open/Closed Principle (OCP) in SOLID and how to implement it with interfaces in .NET?","acceptedAnswer":{"@type":"Answer","text":"The Open/Closed Principle states that a class should be open for extension but closed for modification. In .NET, this is implemented via interfaces and dependency injection: instead of modifying an existing class to add behavior, create a new implementation of the interface. For example, to add a new logger type, create a new class implementing ILogger rather than modifying the existing Logger class. This reduces regressions and improves maintainability."}},{"@type":"Question","name":"What is the Liskov Substitution Principle (LSP) in SOLID and why is it important for polymorphism in .NET?","acceptedAnswer":{"@type":"Answer","text":"LSP states that objects of a derived class should be able to replace objects of the base class without altering program behavior. In .NET, this means subclasses must not violate base class contracts (preconditions, postconditions, invariants). For example, if Bird has a Fly method, creating a Penguin subclass that throws an exception in Fly violates LSP. Prefer composition or more specific interfaces (IFlyable) to respect LSP."}},{"@type":"Question","name":"What is the Interface Segregation Principle (ISP) in SOLID and how to avoid overly broad interfaces in .NET?","acceptedAnswer":{"@type":"Answer","text":"ISP states that no client should be forced to depend on methods it doesn't use. In .NET, this means preferring multiple small specific interfaces over one large generic interface. For example, instead of an IRepository interface with 15 methods, create IReadRepository, IWriteRepository, ISearchRepository. This allows classes to implement only what they need and improves testability by reducing unnecessary dependencies."}},{"@type":"Question","name":"What is the Dependency Inversion Principle (DIP) in SOLID and how to implement it with ASP.NET Core DI?","acceptedAnswer":{"@type":"Answer","text":"DIP states that high-level modules should not depend on low-level modules, both should depend on abstractions (interfaces). In ASP.NET Core, this is implemented by injecting interfaces in constructors rather than concrete classes. For example, injecting IEmailService rather than SmtpEmailService allows changing the implementation without modifying client code. The DI container automatically resolves dependencies, and tests can easily inject mocks."}},{"@type":"Question","name":"What is the purpose of the Strategy pattern in .NET and when to use it instead of a series of if/else?","acceptedAnswer":{"@type":"Answer","text":"The Strategy pattern encapsulates interchangeable algorithms in separate classes implementing a common interface, allowing algorithm selection at runtime. In .NET, use Strategy instead of if/else when you have multiple algorithms for the same task (e.g., different pricing, sorting, compression strategies). This respects the Open/Closed Principle by allowing new algorithms to be added without modifying existing code. Combine with DI to inject the appropriate strategy."}},{"@type":"Question","name":"How to implement the Strategy pattern with Dependency Injection in ASP.NET Core to select a strategy dynamically?","acceptedAnswer":{"@type":"Answer","text":"In ASP.NET Core, register all strategy interface implementations in the DI container, then inject IEnumerable into the client. The client can then select the right strategy via a discriminating property (e.g., strategy.Type). Alternatively, use a factory pattern to resolve the strategy from a parameter. For complex scenarios, combine with Chain of Responsibility pattern or use named services via injected dictionaries."}},{"@type":"Question","name":"What is the purpose of the Decorator pattern in .NET and how to use it with ASP.NET Core middleware pipeline?","acceptedAnswer":{"@type":"Answer","text":"The Decorator pattern dynamically adds responsibilities to an object without modifying its code, by wrapping it in a decorator class. ASP.NET Core middleware pipeline is a perfect example: each middleware decorates the next by adding behavior (logging, authentication, compression) while delegating to the next via next(). This respects the Open/Closed Principle and allows flexible behavior composition. Also use to decorate services via DI with Scrutor."}},{"@type":"Question","name":"How to implement a Decorator to add logging to an existing service in .NET without modifying the original service?","acceptedAnswer":{"@type":"Answer","text":"Create a decorator class that implements the same interface as the service, inject the original service in its constructor and delegate calls while adding logging before/after. In ASP.NET Core, register the decorator in DI with services.Decorate() (via Scrutor) or manually. The decorator respects the Open/Closed Principle by adding behavior without touching the service code. Useful for logging, caching, retry logic, validation."}},{"@type":"Question","name":"What is the role of the Repository pattern in .NET and why use it with Entity Framework Core?","acceptedAnswer":{"@type":"Answer","text":"The Repository pattern abstracts the data access layer by providing an interface for CRUD operations, isolating business logic from persistence implementation (EF Core). This allows easily changing the ORM, facilitates testing with in-memory repositories, and centralizes complex queries. Although EF Core DbContext already acts as a Repository, creating an explicit Repository layer helps respect Domain-Driven Design and limits exposing EF Core details (tracking, migrations) to the business layer."}},{"@type":"Question","name":"When NOT to use the Repository pattern with Entity Framework Core in .NET?","acceptedAnswer":{"@type":"Answer","text":"Don't use Repository if the application is simple and DbContext is sufficient, as it adds unnecessary complexity (over-engineering). DbContext already implements Unit of Work and DbSet acts as Repository. For simple CRUD queries, directly exposing DbContext via services can be more pragmatic. Repository becomes useful for complex applications with Domain-Driven Design, multiple data sources, or strong abstraction needs. Avoid the Generic Repository anti-pattern that exposes IQueryable and leaks EF Core details."}},{"@type":"Question","name":"What is the role of the Unit of Work pattern in .NET and how does Entity Framework Core DbContext implement it natively?","acceptedAnswer":{"@type":"Answer","text":"The Unit of Work pattern maintains a list of modifications (additions, deletions, updates) and commits them in a single transaction. DbContext implements this pattern natively: it tracks changes via ChangeTracker and SaveChanges commits all modifications in an automatic transaction. This ensures data consistency (all modifications succeed or fail together). For complex multi-repository scenarios, creating an explicit UnitOfWork class that encapsulates DbContext and exposes multiple repositories can improve separation of concerns."}},{"@type":"Question","name":"How to combine Repository and Unit of Work patterns in .NET to manage multiple repositories in the same transaction?","acceptedAnswer":{"@type":"Answer","text":"Create an IUnitOfWork interface that exposes multiple repository properties (e.g., Users, Orders, Products) and a SaveChangesAsync method. The implementation encapsulates a shared DbContext and passes this DbContext to all repositories. This ensures all repositories work in the same transaction. Register IUnitOfWork as scoped in DI to have one instance per HTTP request. This pattern is useful for complex multi-entity operations where multiple repositories must collaborate consistently."}},{"@type":"Question","name":"What is the problem with the Generic Repository anti-pattern in .NET that exposes IQueryable?","acceptedAnswer":{"@type":"Answer","text":"Exposing IQueryable in a Generic Repository leaks EF Core implementation details to the business layer, violating encapsulation and making it impossible to change the ORM. IQueryable allows the business layer to build complex queries (Include, Where, OrderBy) that are executed by EF Core, creating tight coupling. Prefer specific methods in repositories (GetUserWithOrders, SearchActiveUsers) that return entities or materialized collections. This respects the abstraction principle and facilitates testing."}},{"@type":"Question","name":"How to implement the Observer pattern in .NET with C# events and delegates?","acceptedAnswer":{"@type":"Answer","text":"The Observer pattern in C# is implemented natively with events and delegates. Define an event in the observable class (e.g., public event EventHandler OrderCreated), and observers subscribe with += (e.g., orderService.OrderCreated += OnOrderCreated). When the event occurs, invoke the event (OrderCreated?.Invoke(this, eventArgs)). For complex scenarios, use IObservable/IObserver (.NET Reactive Extensions) or message brokers (MediatR, MassTransit) to completely decouple publishers and subscribers."}},{"@type":"Question","name":"What is the difference between the Adapter and Facade patterns in .NET?","acceptedAnswer":{"@type":"Answer","text":"Adapter converts the interface of an existing class to another interface expected by the client (e.g., adapting an external API to match a local interface). Facade provides a simplified interface for a complex subsystem (e.g., PaymentFacade class that hides the complexity of multiple payment APIs). Adapter focuses on interface compatibility, Facade on simplification. In .NET, use Adapter to integrate third-party libraries, Facade to simplify using complex systems in the business layer."}},{"@type":"Question","name":"How to implement the Command pattern in .NET with MediatR to handle business operations?","acceptedAnswer":{"@type":"Answer","text":"The Command pattern encapsulates a request as an object, allowing clients to be parameterized with different requests, to queue them or log them. MediatR implements this pattern: create command classes (e.g., CreateOrderCommand) that implement IRequest, and handlers (CreateOrderCommandHandler) that implement IRequestHandler. MediatR decouples the command sender from the handler, facilitates logging, validation and retry. Use with CQRS to separate commands (write) from queries (read)."}},{"@type":"Question","name":"What is the main advantage of the Template Method pattern in .NET with abstract classes and virtual methods?","acceptedAnswer":{"@type":"Answer","text":"The Template Method pattern defines the skeleton of an algorithm in a base class with abstract or virtual methods that subclasses override. This allows reusing the common flow (e.g., connect, process, close) while allowing specific variations. In .NET, use abstract for mandatory steps and virtual for optional steps. Example: abstract ReportGenerator class with GenerateHeader (virtual), GenerateBody (abstract), GenerateFooter (virtual). This respects the DRY principle and facilitates adding new report types."}},{"@type":"Question","name":"How to implement the Chain of Responsibility pattern in .NET to handle ASP.NET Core middleware pipeline?","acceptedAnswer":{"@type":"Answer","text":"The Chain of Responsibility pattern passes a request along a chain of handlers until one handles it. ASP.NET Core middleware pipeline implements this pattern: each middleware can process the request or call next() to pass to the next one. Create custom middleware by implementing a class with InvokeAsync(HttpContext context, RequestDelegate next), register with app.UseMiddleware(). Order matters: middlewares execute in registration order (e.g., Authentication before Authorization). Use for logging, validation, error handling."}},{"@type":"Question","name":"What is the role of the Options pattern in ASP.NET Core and how does it respect SOLID principles?","acceptedAnswer":{"@type":"Answer","text":"The Options pattern in ASP.NET Core allows injecting strongly-typed configurations via POCO classes rather than using IConfiguration directly. Register with services.Configure(configuration.GetSection()), then inject IOptions, IOptionsSnapshot or IOptionsMonitor. This respects the Dependency Inversion Principle (depends on abstractions), the Single Responsibility Principle (separate config class) and facilitates testing by allowing mocked configurations to be injected. Use IOptionsSnapshot for scoped configs, IOptionsMonitor for hot changes."}},{"@type":"Question","name":"How to combine multiple design patterns (Repository, Unit of Work, CQRS, MediatR) in a Clean Architecture in .NET?","acceptedAnswer":{"@type":"Answer","text":"In Clean Architecture .NET: Domain layer defines entities, Application layer contains MediatR commands/queries (CQRS) and Repository interfaces (DIP), Infrastructure layer implements repositories and Unit of Work with EF Core. ASP.NET Core controllers in Presentation layer inject IMediator and send commands/queries. This respects all SOLID principles: SRP (layer separation), OCP (extension via new handlers), LSP (interfaces), ISP (small interfaces), DIP (dependencies to abstractions). Unit tests mock repositories, integration tests use a real DbContext."}}]}