스프링을 사용해야하는 이유

송수용·2022년 6월 1일
0

스프링 특징

스프링은 여러 프레임워크들 중 자바를 기반으로 하는 프레임워크이다.
자바 스프링의 특징은

  1. POJO 기반의 구성 (Plain Old Java Object)
    코드를 개발할 때, 개발자가 특정한 라이브러리나 컨테이너의 기술에 종속적이지 않음을 의미
    Java코드를 이용해서 객체를 구성하는 방식 그대로 스프링에서 사용할 수 있다.
    덕분에, 자유롭게 객체지향적 설계를 구현할 수 있다.
    개발자는 가장 일반적인 형태로 코드를 작성하고 실행할 수 있다는 것이다.
    높은 생산성과 유연한 테스트를 할 수 있다는 장점을 가지게 된다.

  2. DI(Depency Injection,의존성 주입)을 통한 객체 관계 구성

"DI는 객체지향 프로그래밍의 강력한 지원군이다."
의존성 주입은 제어의 역전이 일어나는 것을 전제로 스프링 내부의 객체들간의 관계를 관리할 때
사용한다. 의존성 주입은 특정 개체를 외부에서 결정하여 연결시키는 것을 말한다.
자바에서는 인터페이스를 사용하려 의존적인 관계를 처리한다.

  • 메소드나 객체(bean)의 호출 작업은 제어의 역전을 통해 외부에서 이루어진다.
  • 제어의 역행을 전제조건으로 의존성 주입이 일어난다.
  • 의존성을 가진 객체에 대해 스프링에서 의존성 주입이 발생하도록 한다.
  • 의존성 주입 특성으로 인해 개발자가 POJO 개발이 가능하게 된다.

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

예를 들어, MemberController의 생성자에 @Autowired를 붙임으로써 스프링은 스프링이 저장하고 있는 memberService 객체를 컨트롤러가 생성될 때 가져와 준다.
생성자에 Autowired가 있으면 스프링이 연관된 객체를 스프링 컨테이너에서 찾아서 넣어준다.
이렇게 객체 의존관계를 외부에서 넣어주는 것을 의존성 주입(DI)라고 한다.

스프링이 시작될 때 @Controller @Service @Repository와 같은 컴포넌트들을 스캔하고 스프링의 bean으로 등록된다. 기본적으로 @Component가 있으면 스프링 bean으로 자동등록되며, 위의 세 어노테이션도 @Component를 포함하고 있기에 스프링 bean으로 자동 등록된다.
스프링bean으로 등록된다면 "스프링 컨테이너에서 빈이 관리된다." 라고 말하고
이후 @Autowired 어노테이션으로 등록된 빈들의 의존 관계를 연결한다.

의존성 주입의 방법에는 3가지가 있다
1. 필드 주입
2. Setter주입
3. 생성자 주입(권장)

생성자 주입 권장 이유
1. 순환 의존성 확인: 필드주입으로는 순환 의존성을 파악하기 어렵다.
생성자 주입을 하게 되면 서버 기동 시 순환 의존성을 가지는 요소들을 파악할 수 있게 에러메세지를 표시하면서 서버 기동이 되지 않는다.
2.불변성 : 필드 주입은 final을 선언할 수 없지만 생성자 주입은 final을 선언함으로써 객체가 변하지 않도록 방지해준다.
3.단일 책임 원칙 위반 확인

@Autowired 어노테이션을 이용한 의존성 주입 객체 연결을 할 때 사용, 필드 혹은 생성자에 사용하면 컨트롤러, 서비스 등이 생성될 때 스프링 빈에 등록되어 있는 객체를 가져다 넣어준다.

  1. AOP(Aspect Oriented Programming: 관점지향 프로그래밍) 지원

관심사의 분리를 아주 스마트하고 깔끔하게 처리해준다.

스프링은 AOP를 통해 반복적인 코드를 줄이고 개발자가 핵심 비즈니스 로직에만 집중할 수 있도록 지원한다.

"공통 관심 사항(cross-cutting concern) vs 핵심 관심 사항(core concern)"

비즈니스 로직은 아니지만, 보안, 로그, 트랜잭션과 같이 반드시 처리가 필요한 부분을 스프링에서는 공통 관심사항이라고 한다. 예를 들어 회원가입과 회원 조회에서 시간을 측정하는 기능은 핵심 관심 사항은 아니다. 여기서 시간을 측정하는 기능은 공통 관심 사항이다.
이들을 같은 Class안에 메소드로 구현하면 핵심 비즈니스 로직과 공통 관심사항에 해당하는 로직이 섞여서 유지보수 측면에서 매우 어렵다. 하지만 시간을 측정하는 로직은 별도의 공통 로직으로 만들기도 매우 어렵다. 이 경우 시간을 측정하는 로직을 변경할 때에는 모든 로직을 찾아가며 변경해야하는 불상사가 생긴다.

AOP를 사용해 위 그림처럼 한번에 해결할 수 있다.

AOP를 사용할 객체에는 @Aspect 어노테이션을 붙여줘야한다.

@Around로 AOP를 적용할 객체를 지정한다. 문법을 익히면 반복되는 패턴이다보니 쉽게 구현할 수 있다.

회원가입과 회원 조회와 같은 핵심 관심사항과 시간을 측정하는 공통 관심 사항을 분리했다.
시간을 측정하는 로직을 별도의 공통 로직으로 만들었고 핵심 관심 사항을 유지하는데 편리해졌다.
공통 관심사항 로직을 변경할 일이 생기면 AOP로 사용하는 로직의 코드만 변경하는 된다.
원하는 적용 대상을 구별해 적용도 할 수 있다.

  1. 편리한 MVC구조
  • Model
    어플리케이션의 데이터이며, 모든 데이터 정보를 가공하여 가지고 있는 컴포넌트
    사용자가 이용하려는 모든 데이터를 가지고 있어야한다.
    View 또는 Controller에 대해 어떤 정보도 알 수 없어야 한다.

  • View
    시각적인 UI 요소를 지칭하는 용어
    모델이 가지고 있는 데이터를 저장하면 안됨.
    모델이나 컨트롤러에 대한 정보를 알아선 안되고, 단순 표시 역할만 가짐

  • Controller
    모델과 뷰를 연결해주는 역할
    모델과 뷰에 대한 정보를 알아야함
    모델과 뷰의 변경을 인지하여 대처해야 한다.

profile
#공부중 #협업 #소통중시 #백엔드개발자 #능동적 #워커홀릭 #스파르타코딩 #항해99 #미니튜터 #Nudge #ENTJ #브레인스토밍 #아이디어뱅크

0개의 댓글