🚀 .NET Core 콘솔 앱에서 의존성 주입 사용하기

안녕하세요, 재능넷 독자 여러분! 오늘은 .NET Core 콘솔 애플리케이션에서 의존성 주입(Dependency Injection, DI)을 사용하는 방법에 대해 자세히 알아보겠습니다. 이 글을 통해 여러분은 콘솔 앱에서도 의존성 주입의 강력한 이점을 활용할 수 있게 될 것입니다. 🎉

의존성 주입은 현대 소프트웨어 개발에서 중요한 디자인 패턴 중 하나로, 코드의 유연성, 테스트 용이성, 그리고 유지보수성을 크게 향상시킵니다. 특히 C# 개발자들에게는 필수적인 기술이라고 할 수 있죠.

이 글에서는 의존성 주입의 기본 개념부터 시작하여, .NET Core의 내장 DI 컨테이너를 사용하는 방법, 그리고 실제 콘솔 앱에 적용하는 과정까지 단계별로 살펴볼 예정입니다. 또한, 의존성 주입을 사용할 때의 모범 사례와 주의해야 할 점들도 함께 다루겠습니다.

자, 그럼 지금부터 .NET Core 콘솔 앱의 세계에 의존성 주입이라는 마법을 불어넣어 볼까요? 💫

📚 목차

의존성 주입의 기본 개념
.NET Core의 의존성 주입 컨테이너 소개
콘솔 앱에서 의존성 주입 설정하기
서비스 등록과 수명 관리
의존성 주입을 활용한 콘솔 앱 구조화
실제 예제: 날씨 정보 콘솔 앱 만들기
테스트와 의존성 주입
고급 주제: 커스텀 DI 컨테이너 만들기
성능 최적화 팁
의존성 주입의 모범 사례와 안티 패턴
마무리 및 추가 학습 자료

1. 의존성 주입의 기본 개념 💡

의존성 주입은 객체 지향 프로그래밍에서 중요한 디자인 패턴 중 하나입니다. 이 개념을 이해하기 위해, 먼저 '의존성'이 무엇인지 알아보겠습니다.

의존성이란?

프로그래밍에서 의존성은 한 클래스가 다른 클래스의 기능을 사용할 때 발생합니다. 예를 들어, 다음과 같은 코드를 보겠습니다:


public class EmailService
{
    public void SendEmail(string to, string subject, string body)
    {
        // 이메일 전송 로직
    }
}

public class UserService
{
    private EmailService _emailService = new EmailService();

    public void RegisterUser(string email)
    {
        // 사용자 등록 로직
        _emailService.SendEmail(email, "Welcome!", "Welcome to our service!");
    }
}

위 코드에서 UserService 클래스는 EmailService 클래스에 의존하고 있습니다. 이는 UserService가 EmailService의 인스턴스를 직접 생성하고 사용하기 때문입니다.

의존성 주입의 정의

의존성 주입은 이러한 의존 관계를 외부에서 주입하는 방식입니다. 즉, 클래스가 의존하는 객체를 직접 생성하는 대신, 외부에서 생성된 객체를 받아 사용하는 것입니다.

위의 예제를 의존성 주입 방식으로 변경하면 다음과 같습니다:


public class UserService
{
    private readonly IEmailService _emailService;

    public UserService(IEmailService emailService)
    {
        _emailService = emailService;
    }

    public void RegisterUser(string email)
    {
        // 사용자 등록 로직
        _emailService.SendEmail(email, "Welcome!", "Welcome to our service!");
    }
}

이제 UserService는 IEmailService 인터페이스에 의존하며, 생성자를 통해 이 의존성을 주입받습니다.

의존성 주입의 이점

느슨한 결합: 클래스 간의 의존성이 줄어들어 코드의 유연성이 증가합니다.
테스트 용이성: 목(mock) 객체를 사용하여 단위 테스트를 쉽게 수행할 수 있습니다.
유지보수성: 의존하는 객체를 쉽게 교체할 수 있어 코드 수정이 용이합니다.
재사용성: 동일한 인터페이스를 구현하는 다양한 클래스를 사용할 수 있습니다.

의존성 주입의 유형

의존성 주입은 주로 세 가지 방식으로 이루어집니다:

생성자 주입: 가장 흔히 사용되는 방식으로, 클래스의 생성자를 통해 의존성을 주입받습니다.
속성 주입: 공개 속성을 통해 의존성을 설정합니다.
메서드 주입: 메서드 호출을 통해 의존성을 전달받습니다.

이 중에서 생성자 주입이 가장 권장되는 방식입니다. 왜냐하면 객체 생성 시점에 모든 의존성이 제공되므로, 객체가 항상 유효한 상태를 유지할 수 있기 때문입니다.

의존성 주입의 개념을 이해했다면, 이제 .NET Core에서 이를 어떻게 구현하는지 살펴보겠습니다. .NET Core는 내장된 DI 컨테이너를 제공하여 의존성 주입을 쉽게 구현할 수 있도록 지원합니다.

다음 섹션에서는 .NET Core의 DI 컨테이너에 대해 자세히 알아보겠습니다. 이를 통해 여러분은 콘솔 앱에서 의존성 주입을 효과적으로 사용할 수 있는 기반을 갖추게 될 것입니다. 🚀

2. .NET Core의 의존성 주입 컨테이너 소개 🧰

.NET Core는 강력하고 유연한 내장 의존성 주입 컨테이너를 제공합니다. 이 컨테이너는 Microsoft.Extensions.DependencyInjection 네임스페이스에 포함되어 있으며, ASP.NET Core 애플리케이션뿐만 아니라 콘솔 앱에서도 사용할 수 있습니다.

DI 컨테이너의 주요 구성 요소

IServiceCollection: 서비스 등록을 위한 인터페이스
ServiceProvider: 등록된 서비스의 인스턴스를 제공하는 팩토리
ServiceDescriptor: 서비스 등록 정보를 담는 클래스

서비스 등록 방법

서비스를 등록하는 주요 메서드들은 다음과 같습니다:

AddTransient<TService, TImplementation>(): 요청할 때마다 새 인스턴스 생성
AddScoped<TService, TImplementation>(): 범위(주로 웹 요청) 당 하나의 인스턴스 생성
AddSingleton<TService, TImplementation>(): 애플리케이션 전체에서 하나의 인스턴스만 사용

이러한 메서드들은 IServiceCollection 인터페이스의 확장 메서드로 제공됩니다.

기본 사용 예제

다음은 .NET Core의 DI 컨테이너를 사용하는 기본적인 예제입니다:


using Microsoft.Extensions.DependencyInjection;

public class Program
{
    public static void Main(string[] args)
    {
        // 서비스 컬렉션 생성
        var services = new ServiceCollection();

        // 서비스 등록
        services.AddTransient<IMyService, MyService>();

        // 서비스 프로바이더 생성
        var serviceProvider = services.BuildServiceProvider();

        // 서비스 사용
        var myService = serviceProvider.GetService<IMyService>();
        myService.DoSomething();
    }
}

public interface IMyService
{
    void DoSomething();
}

public class MyService : IMyService
{
    public void DoSomething()
    {
        Console.WriteLine("Doing something...");
    }
}

DI 컨테이너의 작동 원리

.NET Core의 DI 컨테이너는 다음과 같은 과정으로 작동합니다:

서비스 등록: IServiceCollection에 서비스와 그 구현을 등록합니다.
서비스 프로바이더 생성: BuildServiceProvider() 메서드를 호출하여 IServiceProvider 인스턴스를 생성합니다.
서비스 해결: GetService<T>() 또는 GetRequiredService<T>() 메서드를 사용하여 필요한 서비스의 인스턴스를 얻습니다.

DI 컨테이너의 장점

자동 의존성 해결: 복잡한 의존성 그래프도 자동으로 해결합니다.
수명 관리: 서비스의 수명을 쉽게 관리할 수 있습니다.
테스트 용이성: 목(mock) 객체를 쉽게 주입할 수 있어 단위 테스트가 용이합니다.
구성의 중앙화: 애플리케이션의 의존성 구성을 한 곳에서 관리할 수 있습니다.

주의사항

DI 컨테이너를 사용할 때 주의해야 할 점들이 있습니다:

순환 의존성을 피해야 합니다.
서비스의 수명을 적절히 선택해야 합니다.
컨테이너에 너무 많은 책임을 부여하지 않도록 주의해야 합니다.

이제 .NET Core의 DI 컨테이너에 대해 기본적인 이해를 갖게 되었습니다. 다음 섹션에서는 이 지식을 바탕으로 실제 콘솔 앱에서 의존성 주입을 설정하는 방법을 살펴보겠습니다. 🛠️

재능넷에서 제공하는 이 글을 통해, 여러분은 .NET Core의 강력한 DI 기능을 활용하여 더 유연하고 유지보수가 쉬운 콘솔 앱을 만들 수 있을 것입니다. 계속해서 다음 내용을 살펴보시죠!

3. 콘솔 앱에서 의존성 주입 설정하기 🔧

이제 .NET Core 콘솔 애플리케이션에서 의존성 주입을 실제로 설정하는 방법을 살펴보겠습니다. 이 과정은 웹 애플리케이션에서의 설정과는 약간 다르지만, 기본 원리는 동일합니다.

1. 프로젝트 설정

먼저, 새로운 .NET Core 콘솔 애플리케이션을 생성합니다. 그리고 필요한 NuGet 패키지를 추가합니다:


dotnet new console -n MyConsoleApp
cd MyConsoleApp
dotnet add package Microsoft.Extensions.DependencyInjection
dotnet add package Microsoft.Extensions.Hosting

Microsoft.Extensions.Hosting 패키지는 의존성 주입 설정을 더 쉽게 만들어주는 IHost 인터페이스를 제공합니다.

2. 프로그램 구조 설정

이제 Program.cs 파일을 다음과 같이 수정합니다:


using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Hosting;

class Program
{
    static async Task Main(string[] args)
    {
        var host = CreateHostBuilder(args).Build();
        await host.RunAsync();
    }

    static IHostBuilder CreateHostBuilder(string[] args) =>
        Host.CreateDefaultBuilder(args)
            .ConfigureServices((hostContext, services) =>
            {
                // 여기에 서비스를 등록합니다
                services.AddTransient<IMyService, MyService>();
                services.AddHostedService<MyHostedService>();
            });
}

public interface IMyService
{
    void DoWork();
}

public class MyService : IMyService
{
    public void DoWork()
    {
        Console.WriteLine("Doing some work!");
    }
}

public class MyHostedService : IHostedService
{
    private readonly IMyService _myService;

    public MyHostedService(IMyService myService)
    {
        _myService = myService;
    }

    public Task StartAsync(CancellationToken cancellationToken)
    {
        _myService.DoWork();
        return Task.CompletedTask;
    }

    public Task StopAsync(CancellationToken cancellationToken)
    {
        return Task.CompletedTask;
    }
}

3. 코드 설명

CreateHostBuilder 메서드는 IHostBuilder를 생성합니다. 이는 애플리케이션의 구성, 로깅, DI 컨테이너 설정 등을 담당합니다.
ConfigureServices 메서드 내에서 서비스를 DI 컨테이너에 등록합니다.
AddHostedService를 사용하여 MyHostedService를 백그라운드 서비스로 등록합니다. 이 서비스는 애플리케이션이 시작될 때 실행됩니다.
MyHostedService는 생성자를 통해 IMyService를 주입받습니다.

4. 의존성 주입 작동 원리

이 다이어그램은 콘솔 앱에서 의존성 주입이 어떻게 설정되고 실행되는지를 보여줍니다.

5. 실행 및 테스트

이제 애플리케이션을 실행하면, MyHostedService가 시작되고 IMyService의 DoWork 메서드가 호출됩니다.


dotnet run

출력:


Doing some work!

6. 장점 및 주의사항

장점:

코드의 모듈성과 테스트 용이성이 향상됩니다.
서비스의 수명 주기를 쉽게 관리할 수 있습니다.
애플리케이션의 구조가 더 명확해집니다.

주의사항:

간단한 콘솔 앱의 경우, 이러한 설정이 과도할 수 있습니다. 프로젝트의 복잡성을 고려하여 적용하세요.
의존성 주입을 과도하게 사용하면 코드의 복잡성이 증가할 수 있습니다.
성능에 민감한 애플리케이션의 경우, DI 컨테이너의 오버헤드를 고려해야 합니다.

이제 여러분은 .NET Core 콘솔 앱에서 의존성 주입을 설정하는 방법을 배웠습니다. 이 기술을 활용하면, 재능넷과 같은 플랫폼에서 제공하는 다양한 서비스들을 더 효율적으로 통합하고 관리할 수 있습니다. 다음 섹션에서는 서비스 등록과 수명 관리에 대해 더 자세히 알아보겠습니다. 🚀

4. 서비스 등록과 수명 관리 ⏳

의존성 주입 컨테이너를 효과적으로 사용하기 위해서는 서비스 등록 방법과 각 서비스의 수명 주기를 이해하는 것이 중요합니다. .NET Core의 DI 컨테이너는 세 가지 주요 서비스 수명을 제공합니다.

서비스 수명 유형

Transient (일시적)
Scoped (범위)
Singleton (단일)

1. Transient (일시적) 서비스

Transient 서비스는 요청될 때마다 새로운 인스턴스가 생성됩니다.


services.AddTransient<IMyTransientService, MyTransientService>();

사용 사례: 가벼운 상태 비저장 서비스

2. Scoped (범위) 서비스

Scoped 서비스는 주어진 범위 내에서 하나의 인스턴스만 생성됩니다. 웹 애플리케이션에서는 일반적으로 각 HTTP 요청이 하나의 범위가 됩니다.


services.AddScoped<IMyScopedService, MyScopedService>();

사용 사례: 데이터베이스 컨텍스트, 요청별 캐싱

3. Singleton (단일) 서비스

Singleton 서비스는 애플리케이션 수명 동안 단 하나의 인스턴스만 생성됩니다.


services.AddSingleton<IMySingletonService, MySingletonService>();

사용 사례: 전역 상태, 캐싱, 로깅 서비스

서비스 수명 선택 가이드

서비스 등록 방법

서비스를 등록하는 여러 가지 방법이 있습니다:

1. 인터페이스와 구현 클래스 등록


services.AddTransient<IMyService, MyService>();

2. 구체 클래스 직접 등록


services.AddTransient<MyService>();

3. 팩토리 함수를 사용한 등록


services.AddTransient<IMyService>(sp => new MyService());

4. 이미 존재하는 인스턴스 등록


var myService = new MyService();
services.AddSingleton<IMyService>(myService);

주의사항 및 모범 사례

수명 불일치 주의: Singleton 서비스에서 Scoped 또는 Transient 서비스를 주입받지 않도록 주의하세요.
순환 의존성 피하기: A가 B를 의존하고 B가 다시 A를 의존하는 순환 의존성을 만들지 않도록 주의하세요.
인터페이스 사용: 가능한 한 구체 클래스 대신 인터페이스를 통해 의존성을 주입받으세요.
적절한 수명 선택: 서비스의 특성과 사용 패턴을 고려하여 적절한 수명을 선택하세요.
필요한 경우에만 사용: 모든 클래스를 서비스로 등록할 필요는 없습니다. 실제로 의존성 주입이 필요한 경우에만 사용하세요.

실제 예제: 날씨 정보 서비스

간단한 날씨 정보 서비스를 구현하여 각 수명 유형을 실제로 적용해 보겠습니다.


public interface IWeatherService
{
    string GetCurrentWeather();
}

public class WeatherService : IWeatherService
{
    private readonly string _weather;

    public WeatherService()
    {
        // 실제로는 API 호출 등을 통해 날씨 정보를 가져올 것입니다.
        _weather = new[] { "Sunny", "Cloudy", "Rainy" }[new Random().Next(3)];
    }

    public string GetCurrentWeather() => _weather;
}

public class WeatherReporter
{
    private readonly IWeatherService _weatherService;

    public WeatherReporter(IWeatherService weatherService)
    {
        _weatherService = weatherService;
    }

    public void ReportWeather()
    {
        Console.WriteLine($"Current weather: {_weatherService.GetCurrentWeather()}");
    }
}

// 서비스 등록
services.AddTransient<IWeatherService, WeatherService>();
services.AddTransient<WeatherReporter>();

// 사용
var reporter1 = serviceProvider.GetService<WeatherReporter>();
var reporter2 = serviceProvider.GetService<WeatherReporter>();

reporter1.ReportWeather();
reporter2.ReportWeather();

이 예제에서 WeatherService를 Transient로 등록했기 때문에, reporter1과 reporter2는 각각 다른 날씨 정보를 보고할 수 있습니다.

서비스 등록과 수명 관리에 대한 이해는 효과적인 의존성 주입 시스템을 구축하는 데 핵심적입니다. 다음 섹션에서는 이러한 개념들을 활용하여 의존성 주입을 통해 콘솔 앱의 구조를 개선하는 방법을 살펴보겠습니다. 🌟

5. 의존성 주입을 활용한 콘솔 앱 구조화 🏗️

의존성 주입을 활용하면 콘솔 애플리케이션의 구조를 더욱 모듈화하고 유지보수하기 쉽게 만들 수 있습니다. 이 섹션에서는 의존성 주입을 사용하여 콘솔 앱을 구조화하는 방법과 그 이점에 대해 알아보겠습니다.

기본 구조 설계

의존성 주입을 활용한 콘솔 앱의 기본 구조는 다음과 같습니다:

진입점 (Program.cs)
의존성 설정 (Startup.cs)
서비스 인터페이스
서비스 구현
애플리케이션 로직 (AppLogic.cs)

예제: 간단한 할 일 관리 콘솔 앱

간단한 할 일 관리 콘솔 앱을 만들어 의존성 주입을 활용한 구조화를 실습해 보겠습니다.

1. Program.cs


using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Hosting;

class Program
{
    static async Task Main(string[] args)
    {
        var host = CreateHostBuilder(args).Build();
        await host.Services.GetRequiredService<AppLogic>().RunAsync();
    }

    static IHostBuilder CreateHostBuilder(string[] args) =>
        Host.CreateDefaultBuilder(args)
            .ConfigureServices((hostContext, services) =>
            {
                Startup.ConfigureServices(services);
            });
}

2. Startup.cs


using Microsoft.Extensions.DependencyInjection;

public static class Startup
{
    public static void ConfigureServices(IServiceCollection services)
    {
        services.AddSingleton<ITaskRepository, InMemoryTaskRepository>();
        services.AddTransient<ITaskService, TaskService>();
        services.AddTransient<AppLogic>();
    }
}

3. 서비스 인터페이스


public interface ITaskRepository
{
    List<string> GetTasks();
    void AddTask(string task);
}

public interface ITaskService
{
    List<string> GetAllTasks();
    void AddNewTask(string task);
}

4. 서비스 구현


public class InMemoryTaskRepository : ITaskRepository
{
    private readonly List<string> _tasks = new List<string>();

    public List<string> GetTasks() => _tasks;
    public void AddTask(string task) => _tasks.Add(task);
}

public class TaskService : ITaskService
{
    private readonly ITaskRepository _taskRepository;

    public TaskService(ITaskRepository taskRepository)
    {
        _taskRepository = taskRepository;
    }

    public List<string> GetAllTasks() => _taskRepository.GetTasks();
    public void AddNewTask(string task) => _taskRepository.AddTask(task);
}

5. AppLogic.cs


public class AppLogic
{
    private readonly ITaskService _taskService;

    public AppLogic(ITaskService taskService)
    {
        _taskService = taskService;
    }

    public async Task RunAsync()
    {
        while (true)
        {
            Console.WriteLine("\n1. View Tasks");
            Console.WriteLine("2. Add Task");
            Console.WriteLine("3. Exit");
            Console.Write("Choose an option: ");

            var choice = Console.ReadLine();

            switch (choice)
            {
                case "1":
                    ViewTasks();
                    break;
                case "2":
                    await AddTaskAsync();
                    break;
                case "3":
                    return;
                default:
                    Console.WriteLine("Invalid option. Please try again.");
                    break;
            }
        }
    }

    private void ViewTasks()
    {
        var tasks = _taskService.GetAllTasks();
        if (tasks.Count == 0)
        {
            Console.WriteLine("No tasks found.");
        }
        else
        {
            for (int i = 0; i < tasks.Count; i++)
            {
                Console.WriteLine($"{i + 1}. {tasks[i]}");
            }
        }
    }

    private async Task AddTaskAsync()
    {
        Console.Write("Enter new task: ");
        var task = Console.ReadLine();
        if (!string.IsNullOrWhiteSpace(task))
        {
            _taskService.AddNewTask(task);
            Console.WriteLine("Task added successfully.");
        }
        else
        {
            Console.WriteLine("Task cannot be empty.");
        }
    }
}

구조화의 이점

관심사의 분리: 각 컴포넌트가 특정 책임을 가지고 있어 코드의 가독성과 유지보수성이 향상됩니다.
테스트 용이성: 인터페이스를 통한 의존성 주입으로 단위 테스트가 쉬워집니다.
유연성: 구현을 쉽게 교체할 수 있어 요구사항 변경에 대응하기 쉽습니다.
재사용성: 잘 정의된 인터페이스를 통해 컴포넌트를 다른 프로젝트에서도 재사용할 수 있습니다.
확장성: 새로운 기능을 추가하거나 기존 기능을 수정하기 쉬운 구조를 제공합니다.

구조화 시 고려사항

과도한 추상화 주의: 너무 많은 추상화는 오히려 복잡성을 증가시킬 수 있습니다.
적절한 그래뉼래리티: 서비스의 책임 범위를 적절히 설정하여 너무 작거나 너무 크지 않도록 합니다.
명확한 인터페이스 설계: 인터페이스는 그 목적과 책임을 명확히 반영해야 합니다.
순환 의존성 방지: 컴포넌트 간의 순환 의존성을 만들지 않도록 주의합니다.

이렇게 구조화된 콘솔 앱은 재능넷과 같은 플랫폼에서 제공하는 다양한 서비스들을 쉽게 통합하고 관리할 수 있는 기반을 제공합니다. 다음 섹션에서는 이러한 구조를 바탕으로 실제 예제를 통해 더 복잡한 시나리오를 다루어 보겠습니다. 🚀

6. 실제 예제: 날씨 정보 콘솔 앱 만들기 🌤️

이제 우리가 배운 의존성 주입 개념과 구조화 방법을 활용하여 실제로 동작하는 날씨 정보 콘솔 앱을 만들어 보겠습니다. 이 앱은 사용자가 도시 이름을 입력하면 해당 도시의 현재 날씨 정보를 표시합니다.

프로젝트 구조


WeatherApp/
├── Program.cs
├── Startup.cs
├── AppLogic.cs
├── Services/
│   ├── IWeatherService.cs
│   └── OpenWeatherMapService.cs
└── Models/
    └── WeatherInfo.cs

구현 단계

1. 모델 정의 (WeatherInfo.cs)


public class WeatherInfo
{
    public string City { get; set; }
    public double Temperature { get; set; }
    public string Description { get; set; }
}

2. 서비스 인터페이스 정의 (IWeatherService.cs)


public interface IWeatherService
{
    Task<WeatherInfo> GetWeatherAsync(string city);
}

3. 서비스 구현 (OpenWeatherMapService.cs)


using System.Net.Http;
using System.Text.Json;

public class OpenWeatherMapService : IWeatherService
{
    private readonly HttpClient _httpClient;
    private const string ApiKey = "YOUR_API_KEY";

    public OpenWeatherMapService(HttpClient httpClient)
    {
        _httpClient = httpClient;
    }

    public async Task<WeatherInfo> GetWeatherAsync(string city)
    {
        var response = await _httpClient.GetAsync($"http://api.openweathermap.org/data/2.5/weather?q={city}&appid={ApiKey}&units=metric");
        response.EnsureSuccessStatusCode();
        var content = await response.Content.ReadAsStringAsync();
        var jsonDocument = JsonDocument.Parse(content);
        var root = jsonDocument.RootElement;

        return new WeatherInfo
        {
            City = root.GetProperty("name").GetString(),
            Temperature = root.GetProperty("main").GetProperty("temp").GetDouble(),
            Description = root.GetProperty("weather")[0].GetProperty("description").GetString()
        };
    }
}

4. 애플리케이션 로직 (AppLogic.cs)


public class AppLogic
{
    private readonly IWeatherService _weatherService;

    public AppLogic(IWeatherService weatherService)
    {
        _weatherService = weatherService;
    }

    public async Task RunAsync()
    {
        while (true)
        {
            Console.Write("Enter city name (or 'exit' to quit): ");
            var city = Console.ReadLine();

            if (city?.ToLower() == "exit")
                break;

            try
            {
                var weather = await _weatherService.GetWeatherAsync(city);
                Console.WriteLine($"Weather in {weather.City}:");
                Console.WriteLine($"Temperature: {weather.Temperature}°C");
                Console.WriteLine($"Description: {weather.Description}");
            }
            catch (Exception ex)
            {
                Console.WriteLine($"Error: {ex.Message}");
            }

            Console.WriteLine();
        }
    }
}

5. 의존성 설정 (Startup.cs)


using Microsoft.Extensions.DependencyInjection;

public static class Startup
{
    public static void ConfigureServices(IServiceCollection services)
    {
        services.AddHttpClient<IWeatherService, OpenWeatherMapService>();
        services.AddTransient<AppLogic>();
    }
}

6. 프로그램 진입점 (Program.cs)


using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Hosting;

class Program
{
    static async Task Main(string[] args)
    {
        var host = CreateHostBuilder(args).Build();
        await host.Services.GetRequiredService<AppLogic>().RunAsync();
    }

    static IHostBuilder CreateHostBuilder(string[] args) =>
        Host.CreateDefaultBuilder(args)
            .ConfigureServices((hostContext, services) =>
            {
                Startup.ConfigureServices(services);
            });
}

실행 결과


Enter city name (or 'exit' to quit): Seoul
Weather in Seoul:
Temperature: 15.5°C
Description: clear sky

Enter city name (or 'exit' to quit): New York
Weather in New York:
Temperature: 22.3°C
Description: partly cloudy

Enter city name (or 'exit' to quit): exit

코드 설명

의존성 주입: IWeatherService를 AppLogic에 주입하여 느슨한 결합을 구현했습니다.
서비스 수명: HttpClient는 AddHttpClient를 통해 관리되며, AppLogic은 Transient로 등록되었습니다.
관심사 분리: 날씨 정보 조회 로직은 OpenWeatherMapService에 캡슐화되어 있습니다.
예외 처리: 네트워크 오류 등의 예외 상황을 적절히 처리하고 있습니다.

개선 가능한 부분

API 키를 설정 파일로 분리
로깅 기능 추가
캐싱 구현으로 반복 요청 최적화
사용자 입력 유효성 검사 강화

이 예제를 통해 우리는 의존성 주입을 활용하여 모듈화되고 확장 가능한 콘솔 애플리케이션을 구현했습니다. 이러한 구조는 재능넷과 같은 플랫폼에서 제공하는 다양한 API나 서비스를 쉽게 통합할 수 있는 기반을 제공합니다. 다음 섹션에서는 이 애플리케이션에 대한 단위 테스트를 작성하는 방법을 살펴보겠습니다. 🧪

7. 테스트와 의존성 주입 🧪

의존성 주입의 주요 이점 중 하나는 단위 테스트를 쉽게 작성할 수 있다는 것입니다. 이번 섹션에서는 우리가 만든 날씨 정보 콘솔 앱의 일부 컴포넌트에 대한 단위 테스트를 작성해 보겠습니다.

테스트 프로젝트 설정

먼저, 새로운 xUnit 테스트 프로젝트를 생성합니다:


dotnet new xunit -n WeatherApp.Tests

그리고 필요한 NuGet 패키지를 추가합니다:


dotnet add package Moq
dotnet add package Microsoft.Extensions.DependencyInjection

AppLogic 테스트

AppLogic 클래스의 동작을 테스트하기 위해 IWeatherService의 모의 객체(mock)를 사용합니다.


using Moq;
using Xunit;
using System.Threading.Tasks;

public class AppLogicTests
{
    [Fact]
    public async Task RunAsync_ShouldReturnCorrectWeatherInfo()
    {
        // Arrange
        var mockWeatherService = new Mock<IWeatherService>();
        mockWeatherService.Setup(service => service.GetWeatherAsync("Seoul"))
            .ReturnsAsync(new WeatherInfo
            {
                City = "Seoul",
                Temperature = 25.5,
                Description = "Sunny"
            });

        var appLogic = new AppLogic(mockWeatherService.Object);

        // Act & Assert
        using (var consoleOutput = new ConsoleOutput())
        {
            await appLogic.RunAsync();
            
            Assert.Contains("Weather in Seoul:", consoleOutput.GetOutput());
            Assert.Contains("Temperature: 25.5°C", consoleOutput.GetOutput());
            Assert.Contains("Description: Sunny", consoleOutput.GetOutput());
        }
    }
}

// 콘솔 출력을 캡처하기 위한 헬퍼 클래스
public class ConsoleOutput : IDisposable
{
    private readonly StringWriter stringWriter;
    private readonly TextWriter originalOutput;

    public ConsoleOutput()
    {
        stringWriter = new StringWriter();
        originalOutput = Console.Out;
        Console.SetOut(stringWriter);
    }

    public string GetOutput()
    {
        return stringWriter.ToString();
    }

    public void Dispose()
    {
        Console.SetOut(originalOutput);
        stringWriter.Dispose();
    }
}

OpenWeatherMapService 테스트

OpenWeatherMapService를 테스트하기 위해 HttpClient의 동작을 모의화합니다.


using Moq;  using Moq;
using Xunit;
using System.Net.Http;
using System.Threading.Tasks;
using System.Threading;
using Moq.Protected;

public class OpenWeatherMapServiceTests
{
    [Fact]
    public async Task GetWeatherAsync_ShouldReturnCorrectWeatherInfo()
    {
        // Arrange
        var mockHttpMessageHandler = new Mock<HttpMessageHandler>();
        mockHttpMessageHandler.Protected()
            .Setup<Task<HttpResponseMessage>>(
                "SendAsync",
                ItExpr.IsAny<HttpRequestMessage>(),
                ItExpr.IsAny<CancellationToken>()
            )
            .ReturnsAsync(new HttpResponseMessage
            {
                Content = new StringContent(@"{
                    ""name"": ""Seoul"",
                    ""main"": { ""temp"": 25.5 },
                    ""weather"": [{ ""description"": ""clear sky"" }]
                }")
            });

        var client = new HttpClient(mockHttpMessageHandler.Object);
        var weatherService = new OpenWeatherMapService(client);

        // Act
        var result = await weatherService.GetWeatherAsync("Seoul");

        // Assert
        Assert.Equal("Seoul", result.City);
        Assert.Equal(25.5, result.Temperature);
        Assert.Equal("clear sky", result.Description);
    }
}

의존성 주입 컨테이너 테스트

의존성 주입 설정이 올바르게 구성되었는지 확인하는 테스트를 작성할 수 있습니다.


using Microsoft.Extensions.DependencyInjection;
using Xunit;

public class StartupTests
{
    [Fact]
    public void ConfigureServices_ShouldRegisterAllDependencies()
    {
        // Arrange
        var services = new ServiceCollection();

        // Act
        Startup.ConfigureServices(services);

        // Assert
        var serviceProvider = services.BuildServiceProvider();

        Assert.NotNull(serviceProvider.GetService<IWeatherService>());
        Assert.NotNull(serviceProvider.GetService<AppLogic>());
    }
}

테스트 실행

테스트를 실행하려면 다음 명령을 사용합니다:


dotnet test

테스트 커버리지 향상

더 나은 테스트 커버리지를 위해 다음과 같은 추가 테스트 케이스를 고려할 수 있습니다:

잘못된 도시 이름으로 날씨 정보를 요청할 때의 예외 처리
네트워크 오류 시나리오
API 응답 형식이 예상과 다를 때의 처리
여러 도시에 대한 연속적인 날씨 정보 요청

모범 사례

단위 테스트 격리: 각 테스트는 독립적이어야 하며, 다른 테스트의 결과에 영향을 받지 않아야 합니다.
의존성 모의화: 외부 서비스나 데이터베이스와 같은 외부 의존성은 항상 모의 객체로 대체합니다.
테스트 가독성: 각 테스트의 목적이 명확히 드러나도록 작성합니다. Arrange-Act-Assert 패턴을 따르는 것이 좋습니다.
경계 조건 테스트: 정상적인 케이스뿐만 아니라 예외적인 상황도 테스트합니다.
테스트 데이터 관리: 테스트 데이터는 하드코딩보다는 별도의 팩토리 메서드나 테스트 데이터 클래스를 사용하여 관리합니다.

결론

의존성 주입을 활용한 설계는 단위 테스트 작성을 크게 용이하게 합니다. 이는 코드의 품질을 향상시키고, 리팩토링이나 새로운 기능 추가 시 발생할 수 있는 회귀 오류를 빠르게 발견할 수 있게 해줍니다. 재능넷과 같은 플랫폼에서 제공하는 다양한 서비스들을 통합할 때, 이러한 테스트 주도 개발 방식은 안정적이고 유지보수가 용이한 애플리케이션을 만드는 데 큰 도움이 될 것입니다.

다음 섹션에서는 의존성 주입과 관련된 고급 주제인 커스텀 DI 컨테이너 만들기에 대해 알아보겠습니다. 이를 통해 의존성 주입의 내부 동작 원리를 더 깊이 이해할 수 있을 것입니다. 🚀

8. 고급 주제: 커스텀 DI 컨테이너 만들기 🛠️

이번 섹션에서는 간단한 커스텀 DI(의존성 주입) 컨테이너를 직접 구현해 보겠습니다. 이 과정을 통해 DI 컨테이너의 내부 동작 원리를 더 깊이 이해할 수 있을 것입니다.

기본 구조

우리의 커스텀 DI 컨테이너는 다음과 같은 기능을 제공할 것입니다:

서비스 등록
서비스 해결 (의존성 주입)
수명 관리 (Transient, Singleton)

구현


using System;
using System.Collections.Generic;

public class CustomContainer
{
    private Dictionary<Type, ServiceDescriptor> _services = new Dictionary<Type, ServiceDescriptor>();

    public void Register<TService, TImplementation>(ServiceLifetime lifetime = ServiceLifetime.Transient)
        where TImplementation : TService
    {
        _services[typeof(TService)] = new ServiceDescriptor(typeof(TImplementation), lifetime);
    }

    public TService Resolve<TService>()
    {
        return (TService)ResolveService(typeof(TService));
    }

    private object ResolveService(Type serviceType)
    {
        if (!_services.ContainsKey(serviceType))
        {
            throw new Exception($"Service of type {serviceType.Name} is not registered");
        }

        var descriptor = _services[serviceType];

        if (descriptor.Instance != null)
        {
            return descriptor.Instance;
        }

        var actualType = descriptor.ImplementationType;
        var constructor = actualType.GetConstructors()[0];
        var parameters = constructor.GetParameters();
        var parameterInstances = new object[parameters.Length];

        for (int i = 0; i < parameters.Length; i++)
        {
            parameterInstances[i] = ResolveService(parameters[i].ParameterType);
        }

        var implementation = Activator.CreateInstance(actualType, parameterInstances);

        if (descriptor.Lifetime == ServiceLifetime.Singleton)
        {
            descriptor.Instance = implementation;
        }

        return implementation;
    }
}

public class ServiceDescriptor
{
    public Type ServiceType { get; }
    public Type ImplementationType { get; }
    public object Instance { get; set; }
    public ServiceLifetime Lifetime { get; }

    public ServiceDescriptor(Type implementationType, ServiceLifetime lifetime)
    {
        ImplementationType = implementationType;
        Lifetime = lifetime;
    }
}

public enum ServiceLifetime
{
    Transient,
    Singleton
}

사용 예제


// 서비스 정의
public interface IMessageService
{
    string GetMessage();
}

public class EmailService : IMessageService
{
    public string GetMessage() => "This is an email message.";
}

public class SmsService : IMessageService
{
    public string GetMessage() => "This is an SMS message.";
}

public class NotificationService
{
    private readonly IMessageService _messageService;

    public NotificationService(IMessageService messageService)
    {
        _messageService = messageService;
    }

    public void SendNotification()
    {
        Console.WriteLine($"Sending notification: {_messageService.GetMessage()}");
    }
}

// 컨테이너 사용
var container = new CustomContainer();

container.Register<IMessageService, EmailService>(ServiceLifetime.Singleton);
container.Register<NotificationService, NotificationService>();

var notificationService = container.Resolve<NotificationService>();
notificationService.SendNotification();

// 서비스 변경
container.Register<IMessageService, SmsService>(ServiceLifetime.Singleton);

notificationService = container.Resolve<NotificationService>();
notificationService.SendNotification();

코드 설명

Register 메서드: 서비스와 그 구현을 컨테이너에 등록합니다. 서비스의 수명도 지정할 수 있습니다.
Resolve 메서드: 요청된 서비스의 인스턴스를 생성하고 반환합니다. 이 과정에서 재귀적으로 의존성을 해결합니다.
ServiceDescriptor: 서비스의 구현 타입, 수명, 그리고 싱글톤 인스턴스를 저장합니다.
ServiceLifetime: 서비스의 수명을 정의하는 열거형입니다. 여기서는 Transient와 Singleton만 구현했습니다.

한계점

이 간단한 구현에는 몇 가지 한계가 있습니다:

순환 의존성 감지 기능이 없습니다.
Scoped 수명 주기를 지원하지 않습니다.
생성자 주입만 지원하며, 속성 주입이나 메서드 주입은 지원하지 않습니다.
제네릭 타입에 대한 특별한 처리가 없습니다.
성능 최적화가 되어 있지 않습니다.

개선 방향

실제 프로덕션 환경에서 사용할 DI 컨테이너를 만들려면 다음과 같은 기능들을 추가로 구현해야 합니다:

순환 의존성 감지 및 예외 처리
Scoped 수명 주기 지원
다양한 주입 방식 지원 (속성 주입, 메서드 주입)
제네릭 타입 지원
성능 최적화 (예: 리플렉션 결과 캐싱)
스레드 안전성 보장
다양한 등록 방식 지원 (예: 팩토리 함수를 통한 등록)

결론

이 간단한 커스텀 DI 컨테이너 구현을 통해 의존성 주입의 핵심 원리를 이해할 수 있었습니다. 실제 .NET Core의 DI 컨테이너는 이보다 훨씬 복잡하고 다양한 기능을 제공하지만, 기본적인 작동 원리는 유사합니다.

재능넷과 같은 플랫폼에서 제공하는 다양한 서비스들을 통합할 때, 이러한 DI 컨테이너의 내부 동작 원리를 이해하는 것은 매우 유용할 것입니다. 이를 통해 의존성 주입을 더 효과적으로 활용하고, 필요한 경우 커스텀 솔루션을 개발할 수 있는 기반을 갖추게 됩니다.

다음 섹션에서는 의존성 주입을 사용할 때의 성능 최적화 팁에 대해 알아보겠습니다. 이를 통해 대규모 애플리케이션에서도 효율적으로 DI를 활용할 수 있는 방법을 배우게 될 것입니다. 🚀

9. 성능 최적화 팁 🚀

의존성 주입은 코드의 유연성과 테스트 용이성을 크게 향상시키지만, 잘못 사용하면 성능 저하를 초래할 수 있습니다. 이 섹션에서는 .NET Core의 DI 컨테이너를 사용할 때 성능을 최적화하는 방법에 대해 알아보겠습니다.

1. 적절한 수명 주기 선택

서비스의 수명 주기를 적절히 선택하는 것은 성능에 큰 영향을 미칩니다.

Transient: 매번 새 인스턴스를 생성하므로, 상태를 유지하지 않는 가벼운 서비스에 적합합니다.
Scoped: 요청 범위 내에서 재사용되므로, 웹 애플리케이션의 요청별 서비스에 적합합니다.
Singleton: 애플리케이션 수명 동안 하나의 인스턴스만 사용하므로, 상태를 공유하는 서비스에 적합합니다.


// 예시
services.AddTransient<ILightweightService, LightweightService>();
services.AddScoped<IRequestScopedService, RequestScopedService>();
services.AddSingleton<ISharedStateService, SharedStateService>();

2. 생성 비용이 높은 객체는 Singleton으로 등록

데이터베이스 연결, HTTP 클라이언트 등 생성 비용이 높은 객체는 Singleton으로 등록하여 재사용하는 것이 좋습니다.


services.AddSingleton<HttpClient>();
services.AddSingleton<IExpensiveService, ExpensiveService>();

3. 팩토리 패턴 활용

복잡한 객체 생성 로직이 필요한 경우, 팩토리 패턴을 사용하여 성능을 개선할 수 있습니다.


services.AddSingleton<IServiceFactory>(sp =>
{
    return new ServiceFactory(sp);
});

services.AddTransient<IMyService>(sp =>
{
    var factory = sp.GetRequiredService<IServiceFactory>();
    return factory.CreateMyService();
});

4. 레이지 로딩 구현

일부 서비스는 실제로 사용될 때만 초기화하는 것이 유리할 수 있습니다. 이를 위해 Lazy<T>를 활용할 수 있습니다.


services.AddTransient<Lazy<IExpensiveService>>(sp =>
{
    return new Lazy<IExpensiveService>(() => sp.GetRequiredService<IExpensiveService>());
});

5. 객체 풀링 사용

자주 생성되고 파괴되는 객체의 경우, 객체 풀링을 사용하여 성능을 향상시킬 수 있습니다.


services.AddSingleton<ObjectPool<MyExpensiveObject>>(sp =>
{
    return new DefaultObjectPool<MyExpensiveObject>(new DefaultPooledObjectPolicy<MyExpensiveObject>());
});

6. 컨테이너 빌드 최적화

애플리케이션 시작 시 DI 컨테이너를 빌드하는 과정을 최적화할 수 있습니다.


var services = new ServiceCollection();
// 서비스 등록...

var serviceProvider = services.BuildServiceProvider(new ServiceProviderOptions
{
    ValidateScopes = false,
    ValidateOnBuild = false
});

단, 이 옵션들은 개발 환경에서는 활성화하여 잠재적인 문제를 조기에 발견하는 것이 좋습니다.

7. 불필요한 의존성 제거

각 클래스가 정말로 필요한 의존성만 주입받도록 설계하세요. 불필요한 의존성은 성능 저하의 원인이 될 수 있습니다.

8. 프로파일링 및 벤치마킹

성능 최적화를 위해서는 실제 측정이 필요합니다. .NET의 프로파일링 도구와 BenchmarkDotNet 같은 라이브러리를 활용하세요.


[Benchmark]
public void ResolveService()
{
    var service = _serviceProvider.GetService<IMyService>();
    service.DoSomething();
}

9. 컴파일 시점 DI 고려

극단적인 성능이 필요한 경우, 런타임 DI 대신 컴파일 시점 DI를 고려해볼 수 있습니다. 예를 들어, Source Generators를 사용한 DI 구현이 있습니다.

성능 최적화 예제

다음은 위에서 언급한 몇 가지 최적화 기법을 적용한 예제입니다:


public class Startup
{
    public void ConfigureServices(IServiceCollection services)
    {
        // 싱글톤으로 등록하여 재사용
        services.AddSingleton<HttpClient>();

        // 팩토리 패턴 활용
        services.AddSingleton<IServiceFactory, ServiceFactory>();
        services.AddTransient<IMyService>(sp => sp.GetRequiredService<IServiceFactory>().CreateMyService());

        // 레이지 로딩 구현
        services.AddTransient<Lazy<IExpensiveService>>(sp =>
            new Lazy<IExpensiveService>(() => sp.GetRequiredService<IExpensiveService>()));

        // 객체 풀링 사용
        services.AddSingleton<ObjectPool<MyExpensiveObject>>(sp =>
            new DefaultObjectPool<MyExpensiveObject>(new DefaultPooledObjectPolicy<MyExpensiveObject>()));
    }

    public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
    {
        // 애플리케이션 구성...
    }
}

public class ServiceFactory : IServiceFactory
{
    private readonly IServiceProvider _serviceProvider;

    public ServiceFactory(IServiceProvider serviceProvider)
    {
        _serviceProvider = serviceProvider;
    }

    public IMyService CreateMyService()
    {
        // 복잡한 생성 로직...
        return new MyService(_serviceProvider.GetRequiredService<IDependency>());
    }
}

public class MyController : ControllerBase
{
    private readonly Lazy<IExpensiveService> _lazyExpensiveService;
    private readonly ObjectPool<MyExpensiveObject> _objectPool;

    public MyController(Lazy<IExpensiveService> lazyExpensiveService, ObjectPool<MyExpensiveObject> objectPool)
    {
        _lazyExpensiveService = lazyExpensiveService;
        _objectPool = objectPool;
    }

    public IActionResult DoSomething()
    {
        // 필요할 때만 초기화
        var expensiveService = _lazyExpensiveService.Value;

        // 객체 풀에서 객체 가져오기
        var expensiveObject = _objectPool.Get();
        try
        {
            // 작업 수행...
            return Ok();
        }
        finally
        {
            // 객체를 풀로 반환
            _objectPool.Return(expensiveObject);
        }
    }
}

결론

의존성 주입은 강력한 도구이지만, 성능에 미치는 영향을 항상 고려해야 합니다. 위의 최적화 기법들을 적절히 활용하면, 재능넷과 같은 플랫폼에서 제공하는 다양한 서비스들을 효율적으로 통합하면서도 높은 성능을 유지할 수 있습니다. 다음 섹션에서는 의존성 주입의 모범 사례와 안티 패턴에 대해 알아보겠습니다. 이를 통해 더 견고하고 유지보수가 용이한 코드를 작성하는 방법을 배우게 될 것입니다. 💡

10. 의존성 주입의 모범 사례와 안티 패턴 🎭

의존성 주입을 효과적으로 사용하기 위해서는 모범 사례를 따르고 안티 패턴을 피하는 것이 중요합니다. 이 섹션에서는 .NET Core 환경에서의 DI 모범 사례와 피해야 할 안티 패턴에 대해 알아보겠습니다.

모범 사례 (Best Practices)

생성자 주입 사용


public class MyService
{
    private readonly IDependency _dependency;

    public MyService(IDependency dependency)
    {
        _dependency = dependency ?? throw new ArgumentNullException(nameof(dependency));
    }
}

인터페이스에 의존


services.AddTransient<IMyService, MyService>();

적절한 수명 주기 선택


services.AddTransient<IShortLivedService, ShortLivedService>();
services.AddScoped<IRequestScopedService, RequestScopedService>();
services.AddSingleton<ILongLivedService, LongLivedService>();

의존성 최소화


public class GoodService
{
    public GoodService(IDependency1 dep1, IDependency2 dep2)
    {
        // 필요한 의존성만 주입
    }
}

설정 주입


services.Configure<MyOptions>(Configuration.GetSection("MyOptions"));
services.AddTransient<IMyService, MyService>();

public class MyService
{
    public MyService(IOptions<MyOptions> options)
    {
        // 설정 사용
    }
}

팩토리 패턴 활용


services.AddTransient<IMyService>(sp =>
{
    var dependency = sp.GetRequiredService<IDependency>();
    return new MyService(dependency);
});

컴포지션 루트에서만 해결


public class Program
{
    public static void Main(string[] args)
    {
        var host = CreateHostBuilder(args).Build();
        var myService = host.Services.GetRequiredService<IMyService>();
        // 여기서만 서비스를 직접 해결
    }
}

안티 패턴 (Anti-Patterns)

서비스 로케이터 패턴


// 안티 패턴
public class BadService
{
    private readonly IServiceProvider _serviceProvider;

    public BadService(IServiceProvider serviceProvider)
    {
        _serviceProvider = serviceProvider;
    }

    public void DoSomething()
    {
        var dependency = _serviceProvider.GetService<IDependency>();
        // 이는 의존성을 숨기고 테스트를 어렵게 만듭니다.
    }
}

순환 의존성


// 안티 패턴
public class ServiceA
{
    public ServiceA(ServiceB b) { }
}

public class ServiceB
{
    public ServiceB(ServiceA a) { }
}

과도한 추상화


// 안티 패턴
services.AddTransient<IServiceA, ServiceA>();
services.AddTransient<IServiceB, ServiceB>();
services.AddTransient<IServiceC, Service  C>();
services.AddTransient<IServiceD, ServiceD>();
// 모든 것을 추상화하는 것은 과도할 수 있습니다.

컨테이너에 대한 과도한 의존


// 안티 패턴
public class OverlyDependentService
{
    private readonly IServiceProvider _serviceProvider;

    public OverlyDependentService(IServiceProvider serviceProvider)
    {
        _serviceProvider = serviceProvider;
    }

    public void DoSomething()
    {
        var service1 = _serviceProvider.GetService<IService1>();
        var service2 = _serviceProvider.GetService<IService2>();
        var service3 = _serviceProvider.GetService<IService3>();
        // 이는 의존성을 숨기고 테스트를 어렵게 만듭니다.
    }
}

부적절한 수명 주기 사용


// 안티 패턴
services.AddSingleton<IDataContext, DataContext>();
// 데이터 컨텍스트를 싱글톤으로 등록하면 멀티 스레드 환경에서 문제가 발생할 수 있습니다.

정적 클래스 및 싱글톤 패턴 과다 사용


// 안티 패턴
public static class StaticHelper
{
    public static void DoSomething() { }
}

// 대신 인터페이스를 사용하고 DI를 통해 주입받으세요.
public interface IHelper
{
    void DoSomething();
}

services.AddTransient<IHelper, Helper>();

서비스 해결을 위한 `new` 키워드 사용


// 안티 패턴
public class BadService
{
    public void DoSomething()
    {
        var dependency = new Dependency();
        // 이는 DI의 이점을 무시하고 강한 결합을 만듭니다.
    }
}

모범 사례 적용 예제

다음은 위에서 언급한 모범 사례들을 적용한 예제입니다:


public interface IUserService
{
    Task<User> GetUserAsync(int id);
}

public interface IEmailService
{
    Task SendEmailAsync(string to, string subject, string body);
}

public class UserService : IUserService
{
    private readonly IDbContext _dbContext;

    public UserService(IDbContext dbContext)
    {
        _dbContext = dbContext ?? throw new ArgumentNullException(nameof(dbContext));
    }

    public async Task<User> GetUserAsync(int id)
    {
        return await _dbContext.Users.FindAsync(id);
    }
}

public class EmailService : IEmailService
{
    private readonly IOptions<EmailSettings> _emailSettings;
    private readonly ILogger<EmailService> _logger;

    public EmailService(IOptions<EmailSettings> emailSettings, ILogger<EmailService> logger)
    {
        _emailSettings = emailSettings ?? throw new ArgumentNullException(nameof(emailSettings));
        _logger = logger ?? throw new ArgumentNullException(nameof(logger));
    }

    public async Task SendEmailAsync(string to, string subject, string body)
    {
        // 이메일 전송 로직
        _logger.LogInformation($"Sending email to {to}");
        // 실제 이메일 전송 코드...
    }
}

public class UserController : ControllerBase
{
    private readonly IUserService _userService;
    private readonly IEmailService _emailService;

    public UserController(IUserService userService, IEmailService emailService)
    {
        _userService = userService ?? throw new ArgumentNullException(nameof(userService));
        _emailService = emailService ?? throw new ArgumentNullException(nameof(emailService));
    }

    [HttpGet("{id}")]
    public async Task<IActionResult> GetUser(int id)
    {
        var user = await _userService.GetUserAsync(id);
        if (user == null)
        {
            return NotFound();
        }

        await _emailService.SendEmailAsync(user.Email, "User Retrieved", "Your user information was accessed.");

        return Ok(user);
    }
}

// Startup.cs
public class Startup
{
    public void ConfigureServices(IServiceCollection services)
    {
        services.AddDbContext<IDbContext, AppDbContext>(options =>
            options.UseSqlServer(Configuration.GetConnectionString("DefaultConnection")));

        services.AddScoped<IUserService, UserService>();
        services.AddSingleton<IEmailService, EmailService>();

        services.Configure<EmailSettings>(Configuration.GetSection("EmailSettings"));

        services.AddControllers();
    }
}