Dependency Injection을 조금 다르게 보기 시작한 방법 😊🍺

Source: Dev.to

Dependency Injection (DI): 깨끗한 코드뿐 아니라 서버 비용 절감까지

1. 요청의 구조: “객체 클러스터”

요청을 처리하기 위해 애플리케이션은 연결된 체인 형태의 “객체 클러스터”를 생성합니다:

• Controller – 요청의 진입점.
• Services – 비즈니스 로직을 담고 있음.
• Repositories, Logging, and Database Contexts – 데이터 접근 및 진단을 담당.

이것이 OOP의 핵심이며, 모든 것이 객체로 변환되어 처리됩니다. 작업이 끝나면 클러스터는 폐기됩니다.

2. RAM 악몽과 DI의 탄생

DI는 객체 클러스터가 차지하는 RAM 사용량을 줄이기 위해 탄생했습니다. Martin Fowler와 Robert C. Martin(Uncle Bob) 같은 업계 거인들이 널리 알렸지만, .NET 세계에서는 이 객체들의 수명을 조절하는 “심장” 역할을 하게 되었습니다.

3. “생명·죽음” 코디네이터: Singleton, Scoped, Transient

• Transient (단기) – 요청될 때마다 새로 생성됩니다. 종이 냅킨처럼 한 번 쓰고 버리는 느낌입니다. 가볍고 상태가 없는 로직에 적합합니다.
• Scoped (요청 단위) – 단일 HttpContext 전체에서 하나의 인스턴스를 공유합니다. 요청이 끝나면 역할도 끝납니다. 같은 스레드 내에서 동일한 서비스를 여러 번 재생성하지 않으므로 RAM을 크게 절약합니다.
• Singleton (장기) – 애플리케이션이 시작될 때 한 번 생성되어 종료될 때까지 살아 있습니다. 수백만 개의 요청이 공유하는 “빅 보스”와 같습니다. 궁극적인 자원 절약이지만 데이터 동시성에 대한 신중한 처리가 필요합니다.

4. 동전의 다른 면: 디커플링

DI에 대한 제 생각을 읽어주셔서 감사합니다. 처음으로 이 주제에 대해 글을 써보았는데, 다른 관점이 있거나 빠진 부분이 있다면 댓글로 의견을 남겨 주세요! 함께 공유하고 배우며 성장합시다. 🍻