1. Framework / Library
-
Framework : 애플리케이션을 만들기 위해 제공되는 틀 혹은 구조
- 기본 구조가 만들어져 있어 효율적으로 코드 작성 가능
- 규약에 따라 작성하여 효율적으로 유지보수 가능하나 유연한 개발 제한
- 설계와 구현을 재사용 가능하도록 클래스들을 제공 하는 것
- 애플리케이션 흐름의 주도권이 Framework에 있음 -> IOC(Inversion Of Control, 제어의 역전)
-
Library : 필요한 기능을 미리 구현해 놓은 집합체
- 짜놓은 코드 내에서 필요한 기능이 있으면 해당 라이브러리를 호출해서 사용하는 것
- 쉽게 교체 가능하며 필요한 라이브러리를 선택적으로 사용 가능
- 애플리케이션 흐름의 주도권이 개발자에게 있음
2. Spring Framework 특징
1) POJO (Plain Old Java Object)
(1) Java나 Java 사양에 정의된 것 이외에 다른 기술이냐 규약에 얽메이지 않아야 한다.
(2) 특정 환경에 종속적이지 않아야 한다.
-> 객체지향적 설계를 제한 없이 적용 가능
- 다른 환경이나 기술에 종속적이지 않도록 하기 위한 POJO 프로그래밍 코드를 작성하기 위해 IoC/DI, AOP, PSA 지원
2) IoC/DI
출처 : https://docs.oracle.com/cd/B14099_19/web.1012/b14017/overview.htm
(1) IoC (Inversion of Control)
애플리케이션 흐름의 주도권이 사용자에게 있지 않고, Framework이나 서블릿 컨테이너 등 외부에 있는 것, 흐름의 주도권이 뒤바뀐 것
- 클라이언트 요청을 받으면 서블릿 컨테이너가 HttpServletRequest와 HttpServletResponse 객체를 생성하여 post, get 여부에 따라 동적인 페이지를 생성하여 응답
(2) DI (Dependency Injection)
IoC 개념을 구체화시킨 것
- 클래스 내부에서 다른 클래스의 객체를 생성하게 되면 두 클래스 간에 의존 관계가 성립
- 클래스 내부에서 new를 사용해 참조할 클래스의 객체를 직접 생성하지 않고, 생성자 등을 통해 외부에서 다른 클래스의 객체를 전달받고 있다면 의존성 주입이 이루어진것
- new 키워드를 사용하여 객체를 생성할 때, 클래스 간에 강하게 결합(Tight Coupling)
- 어떤 클래스가 인터페이스 같이 일반화된 구성 요소에 의존하고 있을 때, 클래스들 간에 느슨하게 결합(Loose Coupling)
- 느슨한 결합은 요구 사항의 변경에 유연하게 대처 가능
Survlet
클라이언트의 요청을 처리하고 해당 요청의 결과를 클라이언트에게 전송하는 프로그래밍 기술
- 동적인 처리가 가능한 웹
- HTTP 요청을 받아 처리
Survlet Container
작성된 서블릿을 관리
- 웹 서버와 통신
- 서블릿 생명주기 관리
- 멀티스레드 지원 및 관리
- 선언적인 보안 관리
동작과정
- 웹서버가 요청을 받는다.
- 웹서버가 요청을 서블릿 컨테이너로 전달
- 서블릿이 컨테이너에 없다면 서블릿을 동적으로 검색하여 컨테이너의 주소 공간에 로드
- 컨테이너가 서블릿의 init() 메서드를 호출하여 서블릿 초기화
- 컨테이너가 서블릿의 service() 메서드를 호출하여 HTTP 요청을 처리
- 웹서버는 동적으로 생성된 결과를 올바른 위치에 반환
3) AOP (Aspect Oriented Programming)
애플리케이션에 필요한 기능 중에서 공통적으로 적용되는 공통 기능에 대한 관심 지향 프로그래밍
- 애플리케이션 전반에 걸쳐 공통적으로 사용되는 기능에 대한 공통 관심 사항(Cross-cutting concern)
- 애플리케이션의 주목적을 달성하기 위한 핵심 로직에 대한 관심사를 핵심 관심 사항(Core concern)
- 애플리케이션의 핵심 로직에서 로깅, 보안, 트랜잭션 같은 공통 기능 로직을 분리 하는 것
- 중복된 코드를 공통화해서 재사용 가능하게 만드는 것
4) PSA (Portable Service Abstraction)
서비스의 기능을 접근하는 방식 자체를 일관되게 유지하면서 기술 자체를 유연하게 사용할 수 있도록 하는 것
- 인터페이스의 구현체에 직접적으로 연결하는 것이 아닌 인터페이스를 통해 간접적으로 연결하여 어떤 구현체가 와도 일관된 방식으로 해당 서비스의 기능을 사용 가능
* 객체지향 설계 원칙 SOLID
1. SRP(Single responsibility principle)
단일 책임 원칙 : 한 클래스는 하나의 책임만 가져야 한다.
2. OCP(Open/Closed Principle)
개방-폐쇄 원칙 : 소프트웨어 요소는 확장에는 열려 있으나 변경에는 닫혀 있어야 한다.
3. LSP(Liskov Substitution principle)
리스코프 치환 원칙 : 프로그램의 객체는 프로그램의 정확성을 깨뜨리지 않으면서 하위 타입의 인스턴스로 바꿀 수 있어야 한다.
4. ISP(Interface Segregation Principle)
인터페이스 분리 원칙 : 특정 클라이언트를 위한 인터페이스 여러 개가 범용 인터페이스 하나보다 낫다.
5. DIP(Dependency Inversion Principle)
의존관계 역전 원칙 : 추상화에 의존해야지 구체화에 의존하면 안된다.
3. 아키텍처(Architecture)
- 요구 사항을 만족하는 건축물을 짓는 데 필요한 청사진
1) 시스템 아키텍처
- 하드웨어와 소프트웨어를 모두 포함하는 시스템의 전체적인 구성의 큰 그림
- 아키텍처로 해당 시스템이 어떤 하드웨어로 구성되고 어떤 소프트웨어를 사용하는지를 파악 가능
- 시스템 구성 요소들 간 어떻게 상호작용이 일어나는지, 시스템 동작원리 등으로 표현
2) 소프트웨어 아키텍처
- 하드웨어를 제외한 컴퓨터 내의 모든 프로그램을 포괄하는 소프트웨어의 구성을 표현한 큰 그림
Java SE 아키텍처 (출처 : https://docs.oracle.com/javase/1.5.0/docs/index.html)
웹 애플리케이션 아키텍처
1. API 계층(API Layer)
- 클라이언트의 요청을 받아들이는 계층
- 일반적으로 표현 계층(Presentation Layer)라고도 하지만 REST API를 제공하는 애플리케이션의 경우 API 계층이라고 표현
2. 서비스 계층(Service Layer)
- API 계층에서 전달받은 요청을 업무 도메인의 요구 사항에 맞게 비즈니스적으로 처리하는 핵심적인 계층
3. 데이터 액세스 계층(Data Access Layer)
- 서비스 계층에서 처리된 데이터를 데이터베이스 등 저장소에 저장하기 위한 계층
Spring Framework 모듈 아키텍처
출처 : https://docs.spring.io/spring-framework/docs/5.0.0.M5/spring-framework-reference/html/overview.html
모듈(Module)
- 지원되는 여러가지 기능들을 목적에 맞게 그룹화하여 묶어 놓은 것
- Java에선 패키지 단위로 묶여 있으며, 이 패키지 안에 관련 기능을 제공하기 위한 클래스들이 포함되어 있음
- 일반적으로 재사용 가능하도록 라이브러리 형태로 제공
4. Spring Boot
엔터프라이즈 애플리케이션을 개발하기 위한 핵심 기능을 제공하는 Spring Project 중 하나
1. XML 기반의 복잡한 설계 방식 지양
2. 의존 라이브러리 자동 관리
3. 애플리케이션 설정의 자동 구성
- 스타터(Starter) 모듈을 통해 설치되는 의존 라이브러리를 기반으로 애플리케이션의 설정을 자동으로 구성
4. 프로덕션급 애플리케이션의 손쉬운 빌드
5. 내장된 WAS를 통한 손쉬운 배포
-
Spring Boot은 Apache Tomcat이라는 WAS를 내장하고 있어 빌드된 jar 파일을 이용해 명령어 한줄로 실행 가능
- java -jar <jar 파일명>.jar
-
WAS(Web Application Server)
Java 기반의 웹 애플리케이션을 배포하는 일반적인 방식은 개발자가 구현한 코드를 WAR(Web application ARchive) 파일 형태로 빌드 후 WAS(Java에서 서블릿 컨테이너라고도 부름)라는 서버에 배포하여 애플리케이션을 실행
