교재 : 코드로 배우는 스프링 웹 프로젝트(개정판)
출판사 : 남가람북스
⚠이 시리즈에 작성된 내용들은 책을 보고 공부한 내용을 정리한 책이므로 자세한 내용은 책을 참고할 것.
학습목표
- 스프링 프레임워크를 이용해서 의존성 주입에 대한 이해와 테스트
- 스프링에서 XML을 이용하는 객체 관리 방법
- 스프링의 테스트 환경 구축
스프링 프레임워크의 간략한 역사
프레임워크란?
뼈대나 근간을 이루는 코드들의 묶음
그래서 그게 왜 필요한건데?
개발자는 각 개개인의 능력 차이가 큰 직종, 개발자의 구성에 따라 프로젝트 결과 역시 큰 차이가 발생한다.
프레임워크는 이런 상황을 극복하기 위한 코드의 결과물이다.
미리 프로그램의 기본흐름이나 구조를 정하고(뼈대) 모든 팀원들이 이 구조에 자신의 코드를 끼워맞추는 방식을 택한다면 회사 입장에서는 결과물의 일정한 품질이 보장 + 개발자 입장에서는 개발시간 단축이라는 장점들이 생긴다.
스프링 프레임워크는 경량프레임워크라는데?
경량프레임워크는 기존의 복잡한 구동환경과 하드웨어적 구성이 필요한 프레임워크들에 반대되는 개념으로 등장하였다. 특정 기능을 위주로 jar파일 등을 이용해서 모든 개발이 가능하도록 구성된 프레임워크
스프링 프레임워크가 다른 프레임워크랑 다른점은?
- 복잡함에 반기를 들어서 만들어진 프레임워크
- 프로젝트의 전체구조를 설계할 때 유용한 프레임워크
- 다른 프레임워크들의 포용
- 개발 생산성과 개발도구의 지원
스프링의 주요 특징
POJO 기반의 구성
POJO란 Plain Old Java Object의 줄인말이다. 그대로 번역해보자면 평범하고 오래된? 자바 객체인데 이 말의 의미는 스프링에서 객체간의 관계를 구성할 때 별도의 API를 사용하지 않고 그냥 일반적인 java코드를 이용하여 객체를 구성할 수 있다는 것이다.
이는 코드를 작성할 때 개발자가 특정 라이브러리나 컨테이너의 기술에 종속적이지 않다는 것 이라 한다.
의존성 주입(DI)과 스프링
- 의존성
하나의 객체가 다른 객체 없이 제대로 된 역할을 할 수 없다는 것을 의미.
public class Restaurant { private Chef chef; public void cook(){ this chef = new Chef(); ....... }
대략 위와 같은 코드가 있다 하자. 레스토랑 클래스는 요리를 하기위해 쉐프 클래스가 필요하다. 다시말하면 쉐프에게 문제가 생긴다면 레스토랑은 영향을 받게 된다.
이런 경우에
레스토랑(Restaurant)객체는 쉐프(Chef)객체에 의존적이다.
라고 표현한다.
-
주입
외부에서 '밀어 넣는것' 을 의미한다. 위 코드는 레스토랑 객체 내부에서 쉐프를 생성했으므로 주입이 아니다. 아마 setter 나 생성자를 통해 전달받는다면 그것은 주입되었다고 볼 수 있을 것이다. -
의존성 주입(DI, Dependency Injection)
어떤 객체(A)가 필요로 하는 객체(B)를 외부에서 밀어 넣어주는 것.
그렇다면 왜 외부에서 객체를 주입하는 방식을 사용할까??
1. 주입을 받는 입장에서는 어떤 객체인지 신경 쓸 필요가 없다.
2. 어떤 객체에 의존하든 자신의 역할은 변하지 않는다.
스프링에서는 ApplicationContext라는 존재가 있다. 이녀석은 필요한 객체들을 생성하고, 필요한 객체들을 주입하는 역할을 해준다. 개발자들은 객체와 객체를 분리해서 생성하고, 단지 이러한 객체들을 엮는(wiring) 작업을 하는 형태의 개발을 하면 된다.
ApplicationContext가 관리하는 객체들은 빈(Bean)이라고 부르고, 빈과 빈 사이의 의존관계를 처리하는 방식으로 XML, 어노테이션, Java설정 등을 이용한다.
스프링에서는 생성자를 이용한 주입과 setter 메서드를 이용한 주입, 이렇게 두가지 방식으로 의존성 주입을 구현한다.
AOP의 지원 (Aspect Oriented Programming)
좋은 개발환경의 중요 원칙?
개발자가 비즈니스 로직에만 집중할 수 있게 한다.
이 목표를 이루기 위한 원칙은 몇가지가 있지만 가장 쉽게 생각 할 수 있는 것은 반복적인 코드의 제거이다.
- 횡단 관심사(cross-concern)
대부분의 시스템이 공통으로 가지고 있는 보안이나 로그, 트랜잭션과 같이 비즈니스 로직은 아니지만 반드시 처리가 필요한 부분
AOP란 이런 횡단 관심사를 모듈로 분리하는 프로그래밍의 패러다임.
AOP는 AspectJ의 문법을 통해서 작성이 가능하다.(아직 모른다)
- 개발자는 핵심 비즈니스 로직에만 집중하여 코드를 개발할 수 있음
- 각 프로젝트마다 다른 관심사를 적용할 때 코드의 수정을 최소화 할 수 있음
- 원하는 관심사의 유지보수가 수월한 코드를 구성할 수 있음
트랜잭션의 지원
트랜잭션의 개념 - 네이버 지식백과
트랜잭션(transaction)은 하나의 작업을 수행하기 위해 필요한 데이터베이스의 연산들을 모아놓은 것으로, 데이터베이스에서 논리적인 작업의 단위가 된다.
하나의 작업 단위라고 생각하면 될 것 같다.
A가 B에게 돈 10,000원을 계좌이체 한다고 생각을 해보자.
여러가지 연산들이 필요할 것이다. A의 계좌에서 10000을 차감하고, B의 계좌에선 10000을 더하고 등등...
이러한 연산들의 집합(묶음)이 하나의 계좌이체 트랜잭션이 되는것.
이 트랜잭션의 처리는 상황에 따라 복잡할 수도, 아닐 수도 있지만 개발자에게 이를 코드를 작성하여 처리한다는 것은 어찌됬든 상당히 피곤한 일이 될것이다.
스프링에서는 이런 트랜잭션의 관리를 어노테이션이나 XML로 설정할 수 있기에 개발자는 매번 상황에 맞는 코드를 작성할 필요가 없다.
