Lined Notebook

⚙️ 컴포넌트 스캔과 자동 의존관계 설정

by juraffe juraffe

컴포넌트 스캔

우리는 앞서 강의를 들으면서 자연스럽게 다음과 같은 annotation(이하 어노테이션) @Controller, @Service, @Repository 을 접했다. 이건 스프링이라는 프레임워크가 그렇게 설계되었고 그런 스프링을 사용했기에 아무런 의문점이 없이 자연스럽게 접하게 되었기 때문이라고 생각된다. 그렇다면 왜 이런 어노테이션을 붙이는 걸까?

 

스프링에서 Bean이란 스프링 IoC(Inversion of control) 컨테이너에 등록되어 관리되는 객체를 의미한다. 따라서 우리는 Bean에 등록된 객체를 할당하거나 해체를 안 해도 다음과 같은 코드가 할당/해체를 모두 관리할 수 있게 된다.

@Service
class BasicTodoService constructor(
    private val todoRepository: TodoRepository
) : TodoService {

	...생략...
}

@Service class BasicTodoService constructor( private val todoRepository: TodoRepository ) : TodoService { ...생략... }

전통적으로 프로그램은 개발자가 주체가 되어 흐름을 제어했다. 그렇기 때문에 프로그램의 흐름에 대한 부담은 온전히 개발자에게 위임되어 왔다. 때문에 이런 부담과 비용을 프레임워크가 주체가 되어 제어의 흐름을 제어하도록 역전시킨 것이 제어의 역전 IoC이다.

 

그렇다면 프레임워크는 어떻게 자기가 관리해야 할 객체를 알까? 이 물음이 앞서 우리가 접한 @Controller, @Service, @Repository를 자연스럽게 접하게 한 이유이다.

이 3가지 어노테이션은 사실 @Component 어노테이션의 별칭이다. 모두 같은 기능이지만 이름만 다를 뿐인 어노테이션들이다. 그렇다면 스프링은 왜 3가지 어노테이션을 나눠 부르게 된 걸까?, 먼저 다음 사진을 보자

일반적으로 우리가 작성한 코드는 위에서부터 아래로 프로그램의 흐름을 나누게 된다. 예를 들어 회원가입을 작성한다고 생각해보자, 먼저 홈페이지에서 양식에 맞춰 입력이 들어오면(Presentation layer) 우리는 해당 입력값을 요구사항에 맞게 로직을 수행하고(Business logic layer) 최종적으로 해당 입력값을 데이터베이스(MySQL, Oracle, etc...)에 저장하게 된다. 이렇게 회원가입을 하나의 긴 코드를 작성하기보다, 각각을 구분하여 개발하게 되면 수정을 하거나 변경이 있을 경우 적은 수고로 변경을 적용할 수 있다는 장점이 있다.

 

따라서 스프링이 @Component를 @Controller, @Service, @Repository로 나눠 해당 객체를 명시적으로 표현해 코드의 가독성을 높이기 위함이라 생각이 든다.

이렇게 위 3가지 컴포넌트가 붙게 되면 앞서 언급한 스프링 IoC 컨테이너에 등록되고 스프링이 필요한 곳에 적절히 의존성 주입(Dependency injection, 이하 DI)을 가능하게 된다.


https://www.geeksforgeeks.org/what-is-net-3-tier-architecture/

블로그의 정보

🦒 Juraffe's note

juraffe juraffe

활동하기