[Spring] Spring Framework의 탄생과 기능 (上)
나다.
이 글이 뭐하는 글이냐면
우리는 자바를 통해 웹 프로젝트를 제작할 때 Spring이라는 프레임워크를 사용한다.
아주 오래된 시스템의 경우 스트럿츠2 라는 프레임워크를 사용하는 시스템이 있다고 하는데난 식견이 좁아 본 적 없음.
어쨌든 대부분 자바 진영의 경우 Spring으로 통일되어 있다 봐도 무방한 상태인데
혹자들이 "혐자정부 프레임워크"라 부르는 전자정부 프레임워크 또한 Spring을 기반으로 한다.
이번 글에서는 Spring Freamwork의 탄생 배경 기능에 대해 알아보자.
BS(Before Spring) 의 시기
때는 바야흐로 2000년대 초반
Spring이 탄생하기 전 개발자들은 EJB라는 기술을 사용했다.
EJB는 여러 장점을 가지고 있었으나 치명적인 단점들을 가지고 있었는데
- 개같이 복잡하고 X같이 어려운데 느림.
- 객체지향적이지 않음.
- 개발생산성이 딸림.
- 기타 등등.
다음과 같은 단점들로 인해 EJB는 공밀레를 세상에 현신하게 한다.
공밀레 : 공돌이를 녹여 만들어 낸 어떤 것을 뜻하는 말로 에밀레종에서 유래
그리하여 EJB에 시달리는 것에 X 같음을 느낀 "로드 존슨"이라는 개발자가
한 권의 책을 출간하게 되고
"X발 님들아 도저히 EJB 못 쓰겠네요. 제가 안쓰고 만들어봄 ㄱㄷ"
"아 X발 ㅋㅋ 님들아 쓰다 변사체 될 뻔했는데 평가 부탁"
무려 예제 3만줄 짜리의 괴물같은 책을 출간해버린다.
이 책이 그냥 출간에서 끝난 것이 아닌 다른 개발자들이 자신의 서비스에
예제를 접목시켜 사용하는 것을 본 유겐 휠러와 얀 카로프는
"님아 님 예제 좀 지리는 거 같은데 같이 오픈소스 한 번 기깔나게 조져보실? ㅋㅋ"
"ㅇㅋ"
이렇게 스프링의 역사가 시작된다.
AS(Anno Spring) 의 시기
Spring의 탄생은 흡사 개신교도의 예수 탄생과 비슷한 의미를 지녔는데
탄생 이래로 쭉 자바 웹 프로젝트에서 고정적으로 사용되는 것을 보면 그 의미를 알 수 있다.
그냥 이거보다 좋은 게 안 나옴.
이게 하도 좋아서 다른 걸 굳이 만들 이유도 없음.
만들었다 괜히 처 발림. ㅋㅋ
Spring Framework의 골자는 경량 컨테이너로써 자바 객체를 담고 직접 관리하는 것에 있다.
흔히 라이프 사이클(Life Cycle)이라는 말을 들어 봤을 텐데
객체의 라이프 사이클 관리가 프레임 워크를 통해 이뤄지는 것이다.
가장 이해하기 쉬운 방법은 Controller와 Service를 만들어보면 된다.
@Controller
@RequiredArgsConstructor
public class TestController {
private final TestService testService;
public String test(){
testService.어쩌고;
}
}@Service
public class TestService {
public String 어쩌고() {
어쩌고저쩌고;
}
}자바 객체를 담고 직접 관리한다는 뜻의 의미는 본인이 미리 가지고 있던 객체의 인스턴스를 사용자가
요구할 때 보내준다는 뜻이다.
@Service를 통해 TestService는 빈(Bean)으로 컨테이너에 등록된다.
그리고 어디선가 TestService를 주입하는 곳이 있다면 프레임워크가 반응해 본인이 생성해둔 인스턴스를
넘겨주는데 이것을 IOC(제어 역전) 중 DI(Dependency Injection, 의존 주입)이라고 부른다.
하나의 객체가 다른 객체를 사용할 때 각 클래스의 관계를 빈(Bean) 설정 정보를 통해 컨테이너가
자동으로 연결해주는 것이다.
다음으로는
POJO(Plain Old Java Object) 라는 것이다.
그냥 평범한 자바 오브젝트를 의미하는 것으로 그냥 getter와 setter를 가진 단순한
자바 오브젝트로 정의된다.
기존 EJB를 사용하던 때에는 한 가지 기능에 필요 없고 복잡한 로직이 과하게 들어가는
단점을 가지고 있었으나 POJO와 같은 단순 오브젝트는 의존성도 없고
테스트와 유지 보수에 강점을 가지고 있어 다시 뜨기 시작했다.
Spring Freamwork는 POJO 기반 프레임워크임.
이 용어는 00년 9월부터 기라성같은 개발자들에 의해 사용되기 시작했는데 그 중 마틴 파울러 라는 개발자는
이렇게 말 했다.
우리는 사람들이 자기네 시스템에 보통의 객체를 사용하는 것을 왜 그렇게 반대하는지 궁금하였는데, 간단한 객체는 폼 나는 명칭이 없기 때문에 그랬던 것이라고 결론지었다. 그래서 적당한 이름을 하나 만들어 붙였더니, 아 글쎄, 다들 좋아하더라고. - 마틴 파울러
Spring AOP
GOP 출신인 나는 처음 AOP라는 단어를 들었을 때 생각했다.
"ㅅㅂ A중대 지휘소 말하는건가..."
Spring에서 AOP는 Aspect Oriented Programming의 준말로 관점 지향 프로그래밍이라는 뜻이다.
AOP의 골자는 핵심 기능과 공통 기능을 분리시켜 중복되는 코드를 제거하는 것에 있는데
예를 들어 떡볶이를 만든다고 치자.
로제 떡볶이와 존X 매운 떡볶이를 만들어야 한다고 할 때
떡볶이(공통 기능)은 한 번 만들어 놓고
로제 소스(핵심 기능 1) 와 존X 매운 소스(핵심 기능 2)를 만들어서 공통 기능(떡볶이)을 땡겨오면 됨.
개이득.
만약 갑자기
"분모자로 진행시켜"
라고 한다고 해도 그냥 공통 기능인 떡볶이에서 떡만 분모자로 바꿔치기해 주면
핵심 기능인 로제 소스와 존X 매운 소스는 건들이지 않아도 된다.
이 외에도 많은 기능이 있으나 그건 다음 글에서 이어서 쓰도록 하겠다.
많이 읽어봤자 기억에 남지도 않을뿐더러 조금 조금씩 읽는 재미가 있지 않은가.
혹여나 글에 틀린 점이 있다면 그건 내가 허접이라 그런 것이니 이해해 주시길 바란다.
그럼 편안한 하루 보내시길 :)