제어 흐름에 대한 주도성이 누구에게/어디에 있는가 즉 어플리케이션의 Flow(흐름)를 누가 쥐고 있느냐에 따른 차이가 있습니다.
라이브러리는 사용자가 전체적인 흐름을 만들며 라이브러리를 가져다 쓰는 것입니다. 라이브러리를 사용하는 애플리케이션 코드는 애플리케이션 흐름을 직접 제어합니다. 단지 동작하는 중에 필요한 기능이 있을 때 능동적으로 라이브러리를 사용할 뿐입니다.
반면에 프레임워크는 전체적인 흐름을 스스로가 쥐고 있으며 사용자는 그 안에서 필요한 코드를 넣습니다.
프레임워크는 거꾸로 애플리케이션 코드가 프레임워크에 의해 사용되는 것입니다. 보통 프레임워크 위에 개발한 클래스를 등록해두고, 프레임워크가 흐름을 주도하는 중에 개발자가 만든 애플리케이션 코드를 사용하도록 만드는 방식입니다.
프레임워크에는 분명한 제어의 역전 개념이 적용되어 있어야 합니다. 애플리케이션 코드는 프레임워크가 짜놓은 틀에서 수동적으로 동작해야 합니다.
간단히 정리해 보면 라이브러리는 그냥 함수들이나 기능 모음을 가져다가 쓰는 것이고. 프레임워크는 특정 디자인 패턴이나, 전처리 후처리에 필요한 동작과 기능들을 수행하기 위해서 프레임워크가 실행되다가 중간 중간에 특정 비지니스나, 특정 구현 단에서만 사용자의 코드를 lookup(검색)하여 사용하는 형태라고 할 수 있습니다.
1. 복잡함에 반기를 들어서 만들어진 프레임워크일반적인 Java 클래스와 인터페이스를 이용하는 구조를 사용하고 EJB에 비해 가벼움
진입 장벽이 높지 않고 빠른 시간에 엔터프라이즈급의 시스템 구축이 가능
엔터프라이즈급의 시스템이 실패하는 이유를 ‘복잡성’으로 보고 이를 해결하기 위해 나온 경량화된 프레임워크
2. 프로젝트 전체 구조 설계에 유용한 프레임워크스프링은 어느 한 분야에만 집중하지 않고 전체를 설계하는 용도로 사용 가능
이전에 다른 프레임워크들은 웹이나 데이터베이스 등의 전문적인 영역에 대해서만 지원하는 경우가 많았음
3. 다른 프레임워크들의 포용전체 구조에 집중하여 설계되었기 때문에 다른 프레임워크와 공존하는 방식으로 사용 가능 다른 프레임워크들과의 통합을 지원하여 최소한의 수정이 가능 기본 뼈대를 흔들지 않고 여러 종류의 프레임워크를 혼용해서 사용 가능
4. 개발 생산성과 도구의 지원스프링은 이론적으로 개발자가 이해해야하는 부분이 많지만 결과적으로 코드의 양은 줄어둠 XML 설정을 이용하여 유지보수가 용이함 STS, Eclipse, Intellij 등의 플러그인도 지원하여 새로운 개발 도구에 대한 별도의 적응 없이도 개발이 가능
엔터프라이즈급 어플리케이션을 구축할 수 있는 가벼운 솔루션이자, 원스-스탑-숍(One-Stop-Shop)
1. POJO 기반 구성(Plain Old Java Object)
스프링은 내부적으로 객체 간의 관계를 구성할 때 별도의 API 등을 사용하지 않는 POJO(Plain Old Java Object) 만으로 구성이 가능하도록 되어있습니다. 따라서, 일반적인 Java 코드를 이용하여 객체를 구성하는 방식 그대로 스프링에서 사용 가능합니다. 이것은 특정한 라이브러리나 컨테이너에 기술에 종속적이지 않다는 것을 의미합니다. 이로 인하여 개발자는 가장 일반적인 형태로 코드를 작성하고 실행할 수 있기 때문에 높은 생산성과 유연한 테스트를 할 수 있는 장점을 갖게 됩니다.
2. IoC 컨테이너 (Inversion of Control) - 제어역전
제어의 흐름을 사용자가 컨트롤 하지 않고 위임한 특별한 객체에 모든 것을 맡기는 것 자바 코드로 직접 객체간의 결합을 코딩하는 것이 아니라 컨테이너로 처리하여 ( ->DI)결합도를 낮춰 편리함을 제공
3. DL(Dependency Lookup) - 의존성 검색
컨테이너에서는 객체들을 관리하기 위해 별도의 저장소에 빈을 저장하는데 저장소에 저장되어 있는 개발자들이 컨테이너에서 제공하는 API를 이용하여 사용하고자 하는 빈 을 검색하는 방법입니다.
4. DI(Dependency Injection) - 의존성 주입의존성 주입이란 객체가 서로 의존하는 관계가 되게 의존성을 주입하는 것입니다. 객체지향 프로그램에서 의존성 이란 하나의 객체가 어떠한 다른 객체를 사용하고 있음을 의미합니다.DI의 종류는 ‘생성자를 통한 주입’과 ‘set 메서드를 이용한 주입’으로 구분할 수 있으며, 스프링은 두 방식 모두를 지원하고 이에 대한 처리는 간단한 애노테이션으로 대체할 수 있습니다.
IOC에서의 DI는각 클래스 사이에 필요로 하는 의존관계를 빈 설정 정보를 바탕으로 컨테이너가 자동으로 연결해 주는 것입니다.
4. AOP(Aspect Oriented Programming) - 관점지향프로그래밍대부분의 시스템에서 비즈니스 로직은 아니지만 보안, 로그, 트랜잭션과 같이 반드시 처리가 필요한 부분을 스프링에서는 횡단 관심사(cross-concern)라고 합니다. AOP는 이러한 횡단 관심사를 별도 모듈로 분리하는 프로그래밍 패러다임입니다.AOP에 대해 좀더 설명하면 다음과 같습니다.
위의 경우처럼 권한, 로깅, 트랜잭션을 관심사로 봤을 때 AOP에서는 이러한 관심사를 아래와 같이 모두 종단으로 삽입해줍니다. OOP에서 각 객체별로 처리했던 공통적인 관심을 분리하여 별도의 모듈로 만든 뒤 필요한 시점에 자동으로 소스코드가 삽입되도록 합니다.
아래는 OOP 에서의 로직의 흐름을 보여줍니다. 각 로직마다 권한, 로깅, 트랜잭션 처리에 대한 코드를 반복적으로 작성해줘야합니다.
스프링의 AOP는 AspectJ 모듈의 문법을 통하여 작성이 가능하고 이를 이용하여 개발자는 중복 코드를 줄이고 핵심 비즈니스 로직에만 집중하며 원하는 관심사의 유지보수가 수월한 코드를 구성할 수 있습니다.
스프링은 AOP를 통해 반복적인 코드를 줄이고 개발자가 핵심 비즈니스 로직에만 집중할 수 있도록 지원합니다.
5. 완전한 기능을 갖춘 MVC Framework를 제공.
MVC에서는 Model1과 Model2로 나누어져 있으며 일반적인 MVC는 Model2를 지칭합니다.ViewView는 사용자 Interface를 담당하며 사용자에게 보여지는 부분입니다.Model, View, Controller를 나누는 이유는 소스를 분리함으로서 각 소스의 목적이 명확해 지고 유지보수하는데 있어서 용이합니다
model은 DB와 접근하는 계층 , VIEW는 JSP HTML들이 존재, CONTROLLER는 기능에 대한 구현을 담당합니다.
ControllerController에서는 View에 받은 요청을 가공하여 Model(Service 영역)에 이를 전달 하며 Model로 부터 받은 결과를 View로 넘겨주는 역할입니다.
ModelModel에서는 데이터처리를 담당하는 부분입니다.
MVC 구조(Model View Controller) (Model 2) : 사용자 인터페이스와 비지니스 로직을 분리하여 개발 하는 것입니다.
6. 스프링 프레임워크 모듈
필요한 모듈만 가져다 사용할 수 있습니다.
스프링 프레임워크는 약 20개의 모듈로 구성되어 있습니다.
7. 트랜잭션의 지원트랜잭션 : 더 이상 쪼갤 수 없는 최소 작업 단위, 여러 단계를 수행했을 때, 하나라도 실패하면 모두 취소되어야 하며 모두 반영하거나 반영하지 않습니다.스프링에서는 트랜잭션 처리를 애노테이션이나 XML로 설정할 수 있도록 지원합니다.
개발자가 매번 상황에 따라 코드를 작성해줘야 하는 번거로움이 줄어듭니다.
이렇게 함으로써 데이터의 무결성을 보장하는데 트랜잭션 처리는 개발자에게 큰 번거로움을 줍니다
