What is the difference between dependency injection and dependency inversion? Explain with examples in ASP.NET Core WebAPI.

Dependency Injection (DI) and Dependency Inversion Principle (DIP) are closely related concepts in software development, particularly in the context of object-oriented design and frameworks like ASP.NET Core.

Dependency Injection (DI): DI is a design pattern where the dependencies of a class (i.e., the objects it relies on to function) are provided from the outside rather than created internally. This promotes loose coupling between components, making the system more modular, testable, and maintainable.

In ASP.NET Core WebAPI, you often use DI to inject dependencies into controllers, services, or other components. For example, consider a simple service that interacts with a database:

public interface IDataService
{
    void SaveData(string data);
}

public class DatabaseService : IDataService
{
    public void SaveData(string data)
    {
        // Code to save data to the database
    }
}

public class MyController : ControllerBase
{
    private readonly IDataService _dataService;

    public MyController(IDataService dataService)
    {
        _dataService = dataService;
    }

    [HttpPost]
    public IActionResult PostData([FromBody] string data)
    {
        _dataService.SaveData(data);
        return Ok();
    }
}

In this example, MyController depends on IDataService. Instead of creating an instance of DatabaseService inside the controller, we use constructor injection to pass an instance of IDataService to the controller.

Dependency Inversion Principle (DIP):

DIP is a higher-level design principle that states:

1. High-level modules should not depend on low-level modules. Both should depend on abstractions.
2. Abstractions should not depend on details. Details should depend on abstractions.

In simpler terms, it advocates for programming against interfaces or abstract classes rather than concrete implementations.

In ASP.NET Core WebAPI, we can apply DIP by defining interfaces or abstractions for dependencies and then injecting those abstractions rather than concrete implementations. For example, extending the previous example:

public interface IDataService
{
    void SaveData(string data);
}

public class DatabaseService : IDataService
{
    public void SaveData(string data)
    {
        // Code to save data to the database
    }
}

public class MyController : ControllerBase
{
    private readonly IDataService _dataService;

    public MyController(IDataService dataService)
    {
        _dataService = dataService;
    }

    [HttpPost]
    public IActionResult PostData([FromBody] string data)
    {
        _dataService.SaveData(data);
        return Ok();
    }
}

In this example, MyController depends on the IDataService interface rather than the DatabaseService class directly. This adheres to the Dependency Inversion Principle because the high-level module (MyController) depends on an abstraction (IDataService), not a concrete implementation (DatabaseService). This allows for easier substitution of implementations and promotes flexibility and maintainability in the codebase.