Spring
객체지향적으로 설계한 POJO를 유지하며 애플리케이션을 쉽고 효과적으로 개발할 수 있도록 지원하는 프레임워크라고 생각한다.
실패한 해결책 : EJB
자바 엔터프라이즈 시스템 개발이 어려웠던 가장 큰 이유는 근본적인 비즈니스 로직과 엔터프라이즈 기술이라는 두 가지 복잡합이 한데 얽혀 있기 때문이다. EJB의 기본 전략도 이 두가지 종류의 복잡함을 분리하는 것이었다. EJB는 기술적인 복잡함을 애플리케이션의 핵심 로직에서 일부분 분리하는 데 성공하긴 했다. 그러나 EJB라는 환경과 스펙에 종속되는 코드로 만들어져야 하는 더 큰 부담을 안게 되었다. EJB라는 틀 안에서 자바 코드를 만들게 강제함으로써 자바 언어가 원래 갖고 있던 장점마저 잃어버렸다는 사실이다.
비즈니스와 애플리케이션 로직의 복잡함을 상대하는 전략
스프링의 모토는 "기본으로 돌아가자"이다. 자바의 기본인 객체 지향에 충실한 설계가 가능하도록 단순한 오브젝트로 개발할 수 있고, 객체 지향의 설계 기법을 잘 적용할 수 있는 구조를 만들기 위해 DI 같은 유용한 기술을 편하게 적용하도록 도와주는 것이 스프링의 기본 전략이다. 서비스 추상화, 템플릿/콜백, AOP와 같은 스프링의 기술은 DI 없이는 존재할 수 없는 것들이다.
스프링을 사용하면 순수한 비즈니스 로직만을 담고 있는 코드에는 객체지향 분석과 설계에서 나온 도메인 모델을 쉽게 적용할 수 있기 때문이다. 객체 지향적인 특정을 잘 살린 설계는 상속과 다형성, 위임을 포함해서 많은 객체 지향 디자인 패턴과 설계 기법이 잘 녹아들어 갈 수 있었다.
스프링 프레임워크 특징
분리됐지만 반드시 필요한 엔터프라이즈 서비스 기술을 POJO 방식으로 개발된 애플리케이션 핵심 로직을 담은 코드에 제공한다'는 것이 스프링의 가장 강력한 특징과 목표다.
IOC – 프로그램의 제어 흐름을 직접 제어하는 것이 아니라 외부에서 관리당한다면 그것은 제어의 역전이라고 한다.
DI – 애플리케이션 실행 시점에 외부에서 실제 구현객체를 생성하고 클라이언트에 전달해서 클라이언트와 서버의 실제 의존관계가 연결 되는 것은 의존 관계 주입이라고 한다. Ex) A 객체에서 B,C 객체를 사용할 때 A 객체에서 직접 생성하는 것이 아니라, 외부 (IOC 컨테이너)에서 생성된 B, C 객체를 조립(주입)시켜 setter 혹은 생성자를 사용하는 방식. 스프링에서는 객체를 Bean으로 부르고, 이를 관리하는 게 IOC컨테이너이다.
AOP – 애플리케이션에 공통적으로 나타나는 부가적인 기능들을 독립적으로 모듈화하는 프로그래밍 모델. Ex) @Transactional 선언적 트랜잭션 기능을 구현
PSA – 추상화 계층을 사용해 어떤 기술을 내부에 숨기고 개발자에게 편의성을 제공하는 것. EX) JDBC 라는 표준 스펙으로 DBMS를 oracle, Mysql 뭘 사용하든 상관 없음
IOC Container - 스프링은 스테레오 타입의 객체들을 싱글톤으로 관리하고 다른 객체에 주입이 필요하다면 IoC Container가 직접 주입도 시켜준다. 여기서 제어의 역전이 발생한다. 객체는 특정 객체가 아닌 타입에 의존하면서 실제 구현체에 대해서는 모르는 상태를 유지하는 것이다.
왜 컨테이너에 IOC를 하는건데?
1. DI : 개발자가 객체를 new 해서 생성하지 않고, Ioc 컨테이너에 존재하는 Bean 객체를 주입해준다. 해당 기능을 사용하면 싱글톤, 개발자의 편의 등 해결
2. 객체의 Scope : Ioc 컨에티너에 객체의 제어권을 넘겨주면, Ioc 컨테이너가 해당 객체의 Scope를 관리해준다.
3. 라이플 사이클 인터페이스 지원 : 완벽히 구현되지 않은 클래스를 단위 테스트할 떄 도움
IOC 컨테이너는 2가지의 핵심 클래스가 있다.
1. BeanFactory.class(지연로딩) 2. ApplicationContext.class(pre로딩)
참고 :
https://incheol-jung.gitbook.io/docs/q-and-a/spring/spring-1