Framework와 Library

Framework

뼈대나 기본 구조.
애플리케이션 개발에 기본적으로 필요한 구조와 구성을 갖춤으로써 뼈대를 제공하고 그 위에 개발자가 코드를 작성한다.
프레임워크가 원하는 방식대로 다양한 기능을 제공한다.
개발자가 구현한 메서드가 프레임워크에 의해 호출되는 것을 ‘제어의 역전’이라고 한다.

Library

필요한 것들을 미리 구현해놓은 대상, 도구
재사용이 가능하도록 기능을 미리 구현해놓고 필요한 곳에서 호출하여 사용할 수 있도록 만들어진 일련의 집합.

Framework와 Library의 차이점

프레임워크는 틀이고, 라이브러리는 그 안에서 재사용이 가능한 도구.
가장 큰 차이점을 ‘코드 흐름의 제어권’이 누구에게 있느냐이다.
라이브러리는 호출하여 사용하는 개발자에게 제어권이 있다. (능동적)
프레임워크는 틀 안에 이미 제어 흐름에 대한 주도성이 내재되어있다. (수동적)

제어의 역전 (Inversion of Control)

(1) 프레임워크의 event, delegate에 나의 메소드를 등록시켜 제어를 역전시킨다. 전달되는 인자와 반환 형식만 일치하면, 프레임워크 코드는 내가 작성한 객체와 타입은 고려하지 않는다. 등록된 메소드만 감지하여 실행 invoke.

(2) 프레임워크에 정의되어있는 인터페이스, 추상타입을 나의 코드에서 구현, 상속한 후 프레임워크에 넘겨준다. 프레임워크는 인터페이스와 추상을 알고 있으므로 내가 하고자 하는 일련의 작업을 처리할 수 있다. 이는 객체를 프레임워크에 주입하는 것으로, 의존을 주입한다고 한다.

Framework를 사용하는 이유?

효율성. 미리 구조가 구성되어있어 개발자가 구조에 짜맞추는 방식이기 때문에 훨씬 빠르고 성능도 좋다. 개인이 미치는 영향을 최소화하여 일정한 품질을 보장할 수 있다.

그렇다면 왜 Spring을 사용하는가?

스프링은 여러 프레임워크들 중 자바를 기반으로 하는 프레임워크이다.

(1) POJO 기반의 구성 (Plain Old Java Object)

코드를 개발할 때, 개발자가 특정한 라이브러리나 컨테이너의 기술에 종속적이지 않음을 의미한다. Java 코드를 이용해서 객체를 구성하는 방식 그래도 스프링에서 사용할 수 있다. 덕분에, 자유롭게 객체지향적 설계를 구현할 수 있다. (개발자는 가장 일반적인 형태로 코드를 작성하고 실행 가능하다.)

(2) DI (Dependency Injection, 의존성 주입)을 통한 객체 관계 구성

의존성 주입은 제어의 역전이 일어나는 것을 전제로 스프링 내부의 객체들 간의 관계를 관리할 때 사용한다. 의존성 주입은 특정 개체에 필요한 객체를 외부세어 결정하여 연결시키는 것이다. 자바에서는 인터페이스를 사용하여 의존적인 관계를 처리한다.

메소드나 객체의 호출 작업은 제어의 역전을 통해 외부에서 이루어진다.
제어의 역행을 전제조건으로 의존성 주입이 발생하도록 한다.
의존성 주입 특징으로 인해 개발자가 POJO 개발이 가능하게 된다.

실무에서는 주로 정형화된 컨트롤러, 서비스, 레포지토리 같은 코드는 컴포넌트 스캔을 사용한다. 정형화되지 않거나 상황에 따라 구현 클래스를 변경해야하면 설정을 통해 스프링 빈으로 등록한다.

(3) AOP (관점지향 프로그래밍) 지원

스프링은 AOP를 통해 반복적인 코드를 줄이고 개발자가 핵심 비즈니스 로직에만 집중할 수 있도록 지원한다.

“공통 관심 사항(cross-cutting concern) vs 핵심 관심 사항(core concern)”

비즈니스 로직은 아니지만 보안, 로그, 트랜잭션과 같이 반드시 처리가 필요한 부분을 스프링에서는 공통 관심 사항이라고 한다.

예를 들어, 회원가입과 회원 조회에서 시간을 측정하는 기능은 핵심 관심 사항이 아니다. 여기서 시간을 측정하는 기능은 공통 관심 사항이다. 이들을 같은 Class 안에 메소드로 구현하면 핵심 비즈니스 로직과 공통 관심 사항에 해당하는 로직이 섞여서 유지보수가 매우 어렵다. 하지만 시간을 측정하는 로직은 별도의 공통 로직으로 만들기도 매우 어렵다. 이 경우 시간을 측정하는 로직을 변경할 때에는 모든 로직을 찾아가며 변경해야 하는 불상사가 생긴다.

(4) 편리한 MVC 구조

MVC = Model, View, Controller

Model

어플리케이션의 데이터이며, 모든 데이터 정보를 가공하여 가지고 있는 컴포넌트
사용자가 이용하려는 모든 데이터를 가지고 있어야 한다.
View 또는 Controller에 대해 어떤 정보도 알 수 없어야 한다.

View

시각적인 UI요소를 지칭하는 용어.
모델이 가지고 있는 데이터를 저장하면 안된다.
모델이나 컨트롤러에 대한 정보를 알면 안되며, 단순 표시 역할만 가지고 있다.

Controller

모델과 뷰를 연결해주는 역할을 한다.
모델과 뷰에 대한 정보를 알아야한다.
모델과 뷰의 변경을 인지하여 대처해야 한다.

(5) WAS에 독립적인 개발 환경

웹서버는 정적인 데이터를 처리하는 서버로 단순 이미지 HTML을 처리하는 서버이며, WAS(Web Application Server)는 동적인 데이터를 처리하는 서버로 DB연동 데이터 조작등과 같은 처리를 WAS에서 한다.

스프링 Boot 기본 내장 WAS는 Apache Tomcat이다.

@SpringBootApplication을 실행하면 자동으로 웹 서버가 실행된다. 알아두어야할 점은, 스프링 부트가 웹 서버 자체인 것은 아니다. 스프링 부트는 스프링을 편하게 사용하기 위한 툴에 불과하며 웹서버가 실핸되는 것은 스프링 부트가 내장된 웹 서버를 자동으로 구동시킨다는 것이다.

스프링 부트의 내장 WAS를 꼭 사용해야하는 것은 아니며, 자유롭게 변경해서 사용할 수 있다.

마치며, spring이 제공하는 기능이 프로그래머로 하여금 편리하게 개발할 수 있도록 한다. 비즈니스 로직에만 집중할 수 있게 해주는 것이다. 모든 상황에서 필요한 기본적인 코드들은 이미 다 짜여있다. 프로그래머는 해당 상황에 최적화시키기 위한 비즈니스 로직과 관련한 변수와 메소드를 개발하는 데 집중할 수 있다.

추가로, 스프링은 개발자가 기본적인 디자인 패턴(DI, AOP, 서비스 추상화)등을 강제적으로 사용하게끔 함으로서 코드 구조 퀄리티의 최소한을 보장하는 장점도 있다.

[Spring] Framework와 Library의 차이점, 그리고 Framework