✏️ Framework
- 소프트웨어의 구체적인 부분에 해당하는 설계와 구현을 재사용이 가능하게끔 일련의 협업화된 형태로 클래스들을 제공하는 것 (Ralph Johnson)
- 프로그래밍을 하기 위한 어떠한 틀/ 구조 제공
👍 장점
- 효율적인 코드 작성
- 개발자가 애플리케이션의 핵심 로직을 개발하는 것에 집중할 수 있도록 해줌
- 정해진 규약으로 인한 효율적인 애플리케이션 관리 가능
👎 단점
- 사용하고자 하는 Framework에 대한 학습 필요
- 자유롭고 유연한 개발 어려움
✏️ Library
- 애플리케이션을 개발하는 데 사용되는 일련의 데이터 및 프로그래밍 코드
- 애플리케이션을 개발할 때 필요한 기능을 미리 구현해놓은 집합체
- 개발자가 짜 놓은 코드 내에서 필요한 기능이 있으면 해당 라이브러리를 호출해 사용
- 애플리케이션 흐름의 주도권 : 개발자
🆚 Framework
- 애플리케이션 흐름의 주도권 : Framework
✏️ Spring Framework
- POJO (Plain Old Java Object) 기반의 구성
- DI (Dependency Injection) 지원
- AOP (Aspect Oriented Programming, 관점지향 프로그래밍) 지원
- Java 언어를 사용함으로써 얻는 장점
- Java : 정적 타입 언어
- 변수의 타입, 메서드의 입출력이 어떤 타입을 가져야 하는지 강제함
- 여러 사람이 함께 작업할 때, 런타임에 발생하는 오류 사전 방지 가능
- 객체 지향 설계 원칙에 잘 맞는 재사용, 확장 가능한 애플리케이션 개발 스킬 향상 가능
- 보다 나은 성능, 서비스의 안전성이 필요한 복잡한 기업용 엔터프라이즈 시스템을 제대로 구축하기 위한 능력을 기를 수 있음
✏️ Spring Framework의 특징
![](https://velog.velcdn.com/images/hyejuc/post/abdfaa6e-f6e8-49f9-b2db-d218a3893bd4/image.png)
1️⃣ POJO (Plain Old Java Object)
- 아래 두 규칙을 만족해야 POJO 프로그래밍으로 작성한 코드
- Java나 Java의 스펙에 정의된 것 외에는 다른 기술이나 규약에 얽매이지 않아야 함
- 특정 환경에 종속 x
필요한 이유
- 객체지향적인 설계를 제한 없이 적용 가능
- 특정 환경/기술에 종속적이지 않으면
- 재사용, 확장 가능한 유연한 코드 작성 가능
- 테스트 단순해짐
- 저수준 레벨의 기술과 환경에 종속적인 코드를 애플리케이션 코드에서 제거함으로써 코드가 깔끔해짐
- 코드가 깔끔해지므로 디버깅도 상대적으로 쉬워짐
Spring
- Spring에서는 POJO 프로그래밍 코드를 작성하기 위해 3가지 기술 지원
2️⃣ IoC (Inversion of Control)
3️⃣ DI (Dependency Injection)
- 의존성 주입
- 생성자를 통해서 어떤 클래스의 객체를 전달 받는 것
- 생성자의 파라미터로 객체를 전달하는 것 = 외부에서 객체를 주입
4️⃣ AOP (Aspect Oriented Programming)
- 애플리케이션의 핵심 업무 로직에서 로깅, 보안, 트랜잭션과 같은 공통 기능 로직을 분리하는 것
- 공통 관심 사항 (Cross-cutting concern)
- 애플리케이션에 필요한 기능 중에서 공통적으로 적용되는 공통 기능
- 핵심 관심 사항 (Core concern)
- 애플리케이션의 주목적을 달성하기 위한 핵심 로직에 대한 관심사
필요한 이유
- 코드의 간결성 유지
- 객체 지향 설계 원칙에 맞는 코드 구현
- 코드의 재사용
5️⃣ PSA (Portable Service Abstraction)
- 애플리케이션에서 특정 서비스를 이용할 때, 서비스의 기능을 접근하는 방식 자체를 일관되게 유지하면서 기술 자체를 유연하게 사용할 수 있도록 하는 것
- 추상화된 상위 클래스를 일관되게 바라보며 하위 클래스의 기능을 사용하는 것
- 추상화
- 어떤 클래스의 본질적인 특성만을 추출해 일반화하는 것
- 서비스 추상화
- 추상화의 개념을 애플리케이션에서 사용하는 서비스에 적용하는 기법
필요한 이유
- 어떤 서비스를 이용하기 위한 접근 방식을 일관된 방식으로 유지해 애플리케이션에서 사용하는 기술이 변경되더라도 최소한의 변경만으로 변경된 요구 사항을 반영하기 위해
✏️ 아키텍쳐 (Architecture)
- 시스템 아키텍쳐
- 하드웨어와 소프트웨어를 모두 포함하는 어떤 시스템의 전체적인 구성을 큰 그림으로 표현한 것
- 소프트웨어 아키텍쳐
- 하드웨어를 제외한 컴퓨터내의 모든 프로그램의 구성을 큰 그림으로 표현한 것
- ex. Java 플랫폼 아키텍쳐
- 웹 애플리케이션을 위한 아키텍쳐
- 애플리케이션 : 소프트웨어의 한 종류
- 좁은 범위 : 데스크탑/스마트폰에서 사용하는 응용 프로그램
- 넓은 범위 : 클라이언트의 요청을 처리하는 서버 애플리케이션
계층형 아키텍쳐 (N-티어)
- API 계층 (API Layer)
- 클라이언트의 요청을 받아들이는 계층
- 표현 계층 (Presentation Layer)라고도 부름
- 서비스 계층 (Service Layer)
- API 계층에서 전달 받은 요청을 업무 도메인의 요구사항에 맞게 비지니스적으로 처리하는 계층
- 애플리케이션에 있어 핵심이 되는 계층
- 데이터 엑세스 계층 (Data Access Layer)
- 비지니스 계층에서 처리된 데이터를 데이터베이스 등의 데이터 저장소에 저장하기 위한 계층
✏️ Spring Boot
- Spring Framework의 편리함에도 불구하고 Spring 설정의 복잡함으로 인해 Spring 기반 애플리케이션 개발을 시작하기도 전에 어려움을 겪는 문제점을 해결하기 위해 생겨난 Spring project 중 하나
사용해야 하는 이유
- XML 기반의 복잡한 설계 방식 지양
- 의존 라이브러리 자동 관리
- 애플리케이션 설정의 자동 구성
- 스타터(starter) 모듈을 통해 설치되는 의존 라이브러리를 기반으로 애플리케이션 설정 자동 구성
- 프로덕션급 애플리케이션의 손쉬운 빌드
- 내장된 WAS를 통한 손쉬운 배포3