05. 코드로 배우는 스프링 웹 프로젝트 - [스프링의 특징과 의존성 주입] -스프링의 주요 특징 5가지

🖐 스프링의 주요 특징 5가지

• POJO 기반의 구성
• 의존성 주입(DI)을 통한 객체 간의 관계 구성
• AOP(Aspect-Oriented-Programming) 지원
• 편리한 MVC 구조
• WAS의 종속적이지 않은 개발 환경

---

👨🏻‍💻POJO (Plain Old Java Object) 기반의 구성

스프링은 성격 자체가 가벼운 ‘경량 프레임워크’ 이지만, 내부에서는 객체 간의 관계를 구성할 수 있는 특징을 가지고 있다.

 

스프링은 다른 프레임워크들과 달리 이 관계를 구성할 때

별도의 API 등을 사용하지 않는 POJO(Plain Old Java Object)의 구성 만으로 가능하도록 제작되어 있다.

 

쉽게 말해서 ‘우리가 일반적인 Java 코드를 이용해서 객체를 구성하는 방식을 그대로 스프링에서 사용’할 수 있다는 이야기이다.

 

❓ 이것이 중요한 이유는?

코드를 개발할 때 개발자가 특정한 라이브러리나 컨테이너의 기술에 종속적이지 않다는 것을 의미하기 때문이다.

개발자는 가장 일반적인 형태로 코드를 작성하고 실행할 수 있기 때문에 생산성에도 유리하고

코드에 대한 테스트 작업 역시 좀 더 유연하게 할 수 있다는 장점이 생긴다.

---

💉 의존성 주입(Dependency InjectionI)과 스프링

스프링에 빠지지 않는 개념이 ‘의존성 주입’이라는 개념이다. 간단히 알아보자면

'의존성’은 ‘하나의 객체가 다른 객체 없이 제대로 된 역할을 할 수 없다는 것’을 의미한다.

 

음식점의 장사여부 예시(의존성)

💁🏻‍♂️ 서빙을 담당하는 직원이 못 나오는 상황 > 장사 가능

👨🏻‍🍳 주방을 담당하는 직원이 못 나오는 상황 > 장사 불가

 

A객체가 B객체 없이 동작이 불가능한 상황을 ‘A가 B에 의존적이다’라고 표현한다.

('음식점'은 '주방직원'에 의존적이다.)

 

‘주입’은 ‘외부에서 밀어 넣는 것’을 의미한다.

 

음식점 식재료 공급 예시(주입)

🏠 A 가게 : 시장에 가서 직접 공급

🏘 B 가게 : 프랜차이즈 식당이므로 본사의 트럭을 이용해서 자동 공급

---

🏠 A 가게, 🏘 B 가게의 차이는 필요한 객체를 얻기 위해 주체(가게)가 ‘능동적’인지 ‘수동적’인지 에 대한 문제이다.

의존성과 주입을 결합해서 생각해 보면 ‘어떤 객체를 필요로 하면 그 객체를 외부에서 밀어 넣는다’는 의미가 된다.

 

그렇다면 왜 ‘의존성 주입’을 사용할까?

 

음식점 예시(주입) 를 보면 어떤 장점이 보이는가?

‘편리하다’, ‘장사에만 집중할 수 있다’ 같은 장점이 보이지 않는가?

 

이를 코드에 대입해서 살펴보면 아래와 같은 의미로 볼 수 있다.

• 주입을 받는 입장에서는 어떤 객체인지 신경 쓸 필요가 없다.
• 어떤 객체에 의존하든 자신의 역할은 변하지 않는다.

---

 

‘의존성 주입’ 방식을 사용하려면 그림의 오른쪽 바깥쪽 도형처럼 추가적인 하나의 존재가 필요하다.

이 존재는 의존성이 필요한 객체에 필요한 객체를 찾아서 ‘주입’하는 역할(프렌차이즈 본사)을 하게 된다.

 

스프링은 이러한 구조를 만드는데 적합한 구조로 설계되어 있다.

‘ApplicationContext’라는 존재가 필요한 객체들을 생성하고, 필요한 객체들을 주입하는 역할을 해준다.

 

따라서 스프링을 이용하면 개발자들은 기존의 프로그래밍과 달리 객체와 객체를 분리해서 생성하고

이러한 객체들을 역은(wiring) 작업을 하는 형태의 개발을 하게 된다.

 

ApplicationContext가 관리하는 객체들을 ‘빈(Bean)’이라는 용어로 부른다

빈과 빈 사이에는 의존관계를 처리하는 방식으로는 아래와 같은 방식들이 있다.

• XML설정
• 어노테이션 설정
• JAVA 설정

---

👨🏻‍💻 AOP(Aspect Oriented Programming)의 지원

좋은 개발환경의 중요 원칙은 ‘개발자가 비즈니스 로직에만 집중할 수 있게 한다.’이다.

이 목표를 이루기 위해서 가장 쉬운 것은 ‘반복적인 코드의 제거’라고 할 수 있다.

 

스프링은 프레임워크를 이용한 개발에도 이러한 반복적인 코드를 줄이고

핵심 비즈니스 로직에만 집중할 수 있는 방법을 제공한다.

 

대부분의 시스템이 공통으로 가지고 있는 ‘보안’이나 ‘로그’, ‘트렌잭션’과 같이 비즈니스 로직은 아니지만

반드시 처리가 필요한 부분을 스프링에서는 ‘횡단 관심사(cross-concern)’라고 한다.

 

스프링은 이러한 횡단 관심사를 분리해서 제작하는 것이 가능하다.

 

AOP는 이러한 횡단 관심사를 모듈로 분리하는 프로그래밍의 패러다임이다.

스프링은 AOP를 AspectJ의 문법을 통해서 작성할 수 있는데 이를 통해서는 개발자는 아래와 같은 이점이 있다.

 

1. 핵심 비즈니스 로직에만 집중해서 코드를 개발
2. 각 프로젝트마다 다른 관심사를 적용할 때 코드의 수정을 최소화
3. 원하는 관심사의 유지보수가 수월한 코드를 구성

---

🔎 트랙잭션의 지원

데이터 베이스를 이용할 때 반드시 신경 써야 하는 부분은 하나의 업무가 여러 작업으로 이루어지는 경우의 트랜잭션 처리이다.

 

이 트랜잭션 처리는 상황에 따라서 복잡하게 구성될 수도 있고, 아닐 수도 있는데, 그때마다 코드를 이용해서 처리하는 작업은 개발자에게는 상당히 피곤한 일이다.

 

스프링은 이런 트랜잭션의 관리를 어노테이션(@)이나 XML로 설정할 수 있기 때문에 개발자가 매번 상황에 맞는 코드를 작성할 필요가 없도록 설계되어 있다.

 

트랜젝션이란

https://ccomccomhan.tistory.com/49

[DB] - Transaction, 트랜잭션 간단하고 쉽게 이해하기

 

 

 

---

🧹 최종 정리

• 스프링은 내부에서는 객체 간의 관계를 구성할 수 있는 특징이 있다.
• 스프링은 객체 간의 관계 구성시 Java 코드를 이용해서 객체를 구성 할 수 있다.
• 이것은  별도의 API 등을 사용하지 않는 POJO이다. (개발자가 특정한 라이브러리나 컨테이너의 기술에 종속적이지 않다는 것) 
• '의존성’은 ‘하나의 객체가 다른 객체 없이 제대로 된 역할을 할 수 없다는 것’을 의미
• 의존성과 주입을 결합해서 생각해 보면 ‘어떤 객체를 필요로 하면 그 객체를 외부에서 밀어 넣는다’
• ‘ApplicationContext’라는 존재가 필요한 객체들을 생성하고, 필요한 객체들을 주입하는 역할
• 스프링 사용시 객체와 객체를 분리해서 생성하고 이러한 객체들을 역는 작업을 하는 형태의 개발을 하게 된다
• ApplicationContext가 관리하는 객체들을 ‘빈(Bean)’이라는 용어로 부른다
• '빈'들의 의존관계를 처리하는 방식으로는 XML설정, 어노테이션 설정, JAVA 설정 등이 있다.
• 개발자는 반복적인 코드의 제거를 통하여 비즈니스 로직에만 집중할 수 있어야 한다.
• 반드시 처리할 부분을 ‘횡단 관심사(cross-concern)’라고 한다.
  스프링은 이러한 횡단 관심사를 분리해서 제작하는 것이 가능하다.
  AOP는 이러한 횡단 관심사를 모듈로 분리하는 프로그래밍의 패러다임이다.
  스프링은 AOP를 AspectJ의 문법을 통해서 작성할 수 있는데 이를 통해서는 개발자는 아래와 같은 이점이 있다.
  • 핵심 비즈니스 로직에만 집중해서 코드를 개발
  • 각 프로젝트마다 다른 관심사를 적용할 때 코드의 수정을 최소화
  • 원하는 관심사의 유지보수가 수월한 코드를 구성

 

 

 

 

위 내용은 코드로 배우는 스프링 웹 프로젝트 교재를 참고하여 작성되었습니다.

코드로 배우는 스프링 웹 프로젝트 - YES24