Spring 프레임워크_Chapter01_프레임워크 기초

1. 웹 애플리케이션

일반적인 웹 시스템은 정적 컨텐츠인 HTML와 동적 컴텐츠인 JSP으로 나눌 수 있다.

• HTML 
  웹 브라우저가 웹 서버로부터 저장된 HTML을 읽어와 표현한다.
• JSP
  웹 브라우저가 웹 서버에 동적 페이지를 요청하면 이 요청을 애플리케이션 서버가 실행하고, 처리결과(데이터베이스 조회등)를 브라우저가 HTML 형식으로 받아서 표현한다.

2.스프링의 등장

스프링 전에는 EJB라는 분산 환경에서의 트랜잭션 처리를 위한 컴포넌트를 사용했다.

JSP와 서블릿은 프레젠테이션을 구현했고, EJB는 비즈니스 로직을 구현했다.

하지만 J2EE 버전업과 함께 EJB 복잡도는 높아지고 확장성은 떨어지는등 문제가 생겨 그것을 보완하기 위해 등장했다.

 

스프링 프레임워크는 자바 플랫폼을 위한 오픈소스 애플리케이션 프레임워크이다.

POJO(Plain Old Java Object)지원을 통해 기존 EJB의 문제점인 복잡성을 줄였다.

POJO란, 객체 지향적인 원리에 충실하면서 환경과 기술에 종속되지 않고 필요에 따라 재활용될 수 있는 방식으로 설계된 오브젝트를 말한다. 그러한 POJO에 애플리케이션의 핵심로직과 기능을 담아 설계하고 개발하는 방법을 POJO 프로그래밍이라고 할 수 있다.

 

POJO의 조건

1. 특정 규약에 종속되지 않는다.

 자바언어와 꼭 필요한 API외에는 종속되지 말아야한다. EJB2와 같이 특정 규약을 따라 만들게 하는 경우는 대부분 규약에서 제시하는 특정 클래스를 상속하도록 요구한다. 그럴 경우 자바의 단일 상속 제한 때문에 더이상 해당 클래스에 객체지향적인 설계 기법을 적용하기가 어려워지는 문제가 생긴다.

 

2. 특정 환경에 종속되지 않는다.

  특정 기업의 프레임워크나 서버에서만 동작가능한 코드라면 POJO라 할 수 없다. POJO는 환경에 독립적이여야한다. 특히 비지니스 로직을 담고 있는 POJO 클래스는 웹이라는 환경 정보나 웹 기술을 담고 있는 클래스나 인터페이스를 사용해서는 안된다. 설령 나중에는 웹 컨트롤러와 연결되서 사용될 것이 분명하더라도 직접적으로 웹이라는 환경으로 제한해버리는 오브젝트나 API에 의존해서는 안된다. 그렇게 되면 웹 외의 클라이언트가 사용하지 못하기 때문이다.

 

3. 객체 지향적 원리에 충실해야한다.

  POJO는 객체지향적인 자바언어의 기본에 충실하게 만들어져야한다. 자바 언어 문법을 사용했다고해서 자동적으로 객체지향 프로그래밍과 객체지향 설계가 적용됬다고 볼 수는 없다. 책임과 역할이 각기 다른 코드를 한 클래스에 몰아넣어 덩치큰 만능 클래스를 만들고 상속과 다형성의 적용이 아닌 if/switch문으로 가득 설계된 오브젝트라면 POJO라고 부르기 힘들다.

 

[출처] https://doing7.tistory.com/81

3. 웹 어플리케이션 아키텍처(3-Tier)

웹 어플리케이션 아키텍처는 물리층인 티어(Tier)와 논리층인 레이어(Layer)로 구분한다.

• 클라이언트 층(Tier)(PC, 스마트폰)
• 중간 층(Tier)(애플리케이션 서버)
  • 프레젠테이션 층(Layer) : 사용자 인터페이스와 컨트롤러를 제공(Controller)
  • 비즈니스 로직 층(Layer) : 비즈니스 로직을 제공(Service)
  • 데이터 엑세스 층(Layer) : 데이터 엑세스를 추상화(DAO : Data Access Object)
• EIS 층(Tier)(DB, 레거시 시스템)

오목형 레이어

표현 층 또는 데이터 엑세스 층이 변경되어도 비즈니스 로직층에는 영향을 최소하는 방법이다.

레이어 층 도입과 함께 결합 부분에 약한 결합 설계 구현(인터페이스 도입)이 필요하다.

 

4.프레젠테이션 층(presentation Layer)

프레젠테이션층은 사용자 인터페이스와 컨트롤러를 제공하는 역할을 한다.

컨트롤러는 사용자 인터페이스를 통해 사용자의 입력을 받아 적정한 로직을 호출하고, 그 결과를 사용자 인터페이스로 변환하는 작업을 한다.

사용자 인터페이스는 화면 인터페이스를 의미하며 예로는 Vue, React, Angular등 클라이언트 프레임워크들이 있다.

• 모델 1 방식
  JSP만 구현 개발하거나 Java bean을 포함한 개발하는 방식을 의미하며, JSP에 뷰와 비즈니스 로직이 혼재되어 복잡도가 높다.
• 모델 2방식(MVC2)
  • 모델(Model) : 뷰에 필요한 비즈니스 영역의 로직을 처리한다.
  • 뷰(View) : 비즈니스 영역에 대한 브레젠테이션 뷰(결과 화면)를 담당한다.
  • 컨트롤러(Controller) : 사용자의 입력처리와 화면의 흐름 제어를 담당한다.

5. 비즈니스 로직 층(Business logic Layer)의 역할

비즈니스 로직은 유즈케이스(Use Case)로 표현되는 특정 업무 처리를 위한 서비스와 도메인으로 구성되어있다.

개발, 운영 업무의 경우 웹 애플리케이션의 기능 추가와 변경은 비즈니스 로직을 변경한다.

유즈케이스는 시스템을 어떻게 사용하는지를 나타내는 것이다.

시스템의 기본적인 기능들(사용자가 시스템을 사용하여 어떤 일들을 할 수 있는지, 시스템이 어떤 방식으로 반응하는지)를 나타내는 것이다.

각각의 유즈케이스들은 각각 하나의 역할만을 설명한다.

 

 Usecase 다이어그램의 기본 구성

 유즈케이스는 다음과 같은 요소들로 구성되는 다이어그램으로, UML(Unified Modeling Language)로 표현한다.

• 액터 : 시스템을 이용하려고 하는 서브젝트 외부의 사람, 혹은 시스템. 스틱맨으로 표현하기도 하고, 박스로 표현하기도 함
• 유즈케이스 : 시스템 기능의 주요한 조각이다.
• 서브젝트 : 주제의 범위를 나타내는 것이다.

트랜잭션 스크립트 패턴

트랜잭션 스크립트는 하나의 트랜잭션으로 구성된 로직을 단일 함수 또는 단일 스크립트에서 처리하는 구조이다.

비즈니스 로직은 서비스 클래스에 포함되며, 도메인은 가능한 한 로직을 포함하지 않고 단순한 값만 저장한다.

• VO(Value Object) : 사용 되는 값이 객체로 표현 되며, 값 변경이 없는 경우를 말한다.
• DTO(Data Transfer Object) : 데이터의 전송을 위한 객체이며, 비즈니스 로직까지 담아서 사용하기도 한다.

구현 방법의 단순함 때문에 구현이 쉽지만, 비즈니스 로직이 복잡해질수록 난잡한 코드를 만들게 된다.

 

트랜잭션 관리

트랜잭션의 ACID (Atomicity, Consistnecy, Isolation, Durability)특성 중 원자성과 독립성을 관리한다.

원자성은 트랜잭션 내의 모든 처리는 전부 실행됐거나 아무것도 실행되지 않는것을, 독립성은 병행해서 실행되는 트랜잭션 간에는 간섭 받지 않고 독립적임을 뜻한다.

 

트랜잭션 경계

트랜잭션 경계는 프레젠테이션과 비즈니스 로직 층 사이에 존재하는 것이 일반적이며,

프레젠테이션 층에 공개된 비즈니스 로직층의 서비스 클래스의 메서드가 호출되면 트랜잭션이 시작되고, 서비스 클래스의 메서드가 종료되고 프레젠테이션 층의 클래스로 되돌아갈 때 트랜잭션이 종료된다.

• 명시적 트랜잭션
  트랜잭션 시작과 커밋, 롤백과 같은 RDB(Relational Data Base)에 대한  트랜잭션 관리를 소스 코드로 명시하는 것
• 선언적 트랜잭션
  프레임워크에서 제공하는 정의 파일 선언을 통해 트랜잭션 관리

 

6.데이터 액세스 층의 역할

데이터 액세스 층은 RDB 액세스를 비즈니스 로직으로 숨기고, 비즈니스 로직에 필요한 데이터를 테이블에서 취득해서 오브젝트에 매칭한다. 이때 오브젝트와 RDB를 매핑하는 것을 O/R 매핑이라한다.

DB 액세스 프레임워크의 종류로는 다음과 같다.

• Hybernate : 대표적인 ORM(O/R Mapping 프레임워크)
• Mybatis, 스프링 JDBC : SQL 문 사용 전제로 한 DB 액세스 프레임워크

부품화

개발 효율성과 유연성 향상을 위해서는 티어 또는 레이어를 통해 부품화를 하는 것이 좋다.

부품이 큰 쪽이 티어, 레이어 그리고 작은 부품은 패키지 또는 컴포넌트라 하며 부품화를 위해서는 인터페이스가 중요하다.

부품화를 위해서 2가지 중요한 점은 다음과 같다.

• 연결해야 할 부품 간에 결국 중요한 부품이 인터페이스를 가진다.
• 절대적 기준은 없다. 성능이 허용하는 한 부품화할 필요가 있는 만큼 부품화한다.

7. 웹 어플리케이션이 안고 있는 문제

웹 어플리케이션이 안고 있는 문제는 크게 4가지이다.

• EJB의 문제(현재 해결)
• 오브젝트 생명 주기
  싱글톤 구현 필요한데 복잡
• 부품화 문제
  인터페이스 구현과 비의존 구현하기 위서는 고도의 기술이 필요하다.
• 기술 은닉과 부적절한 기술 은닉
  여러 클래스에 걸쳐 존재하는 예외 처리, 로깅, 트랜잭션은 프로그램 가독성을 훼손하고, 부품화와 테스팅에 비효과적이다.

이 모든 문제를 해결을 하기위해 스프링 프레임워크를 사용하는 것이다.

• 오브젝트 생명 주기는 DI(Dependency Injection)컨테이너로 해결
• 부품화 문제는 DI컨테이너로 해결
• 기술 은닉과 부적절한 기술 은직 문제는 AOP(Aspect Oriented Programming)로 해결

 

8.스프링 개요

스프링 프레임워크의 주요 특징을 뽑으면 다음과 같다.

• POJO(Plain Old Java Object) 관리
  특정한 인터페이스를 구현하거나 상속을 받을 필요가 없는 가벼운 객체를 관리한다.
• IOC(Inversion of Control) 경량 컨테이너
  객체 생성과 객체 간 의존 관계 연결을 개발자의 소스 코드가 아닌 스프링 프레임워크가 제공하는 DI 컨테이너가 대신해 주기 때문에 제어가 역전되었다고 정의한다.
• DIxAOP(Dependency Injection, Aspect Oriented Programming) 지원
  • DI : 각각의 계층이나 서비스들 간에 객체 의존성이 존재할 경우 프레임워크가 객체 간의 의존 관계를 만들어 준다. (변경 용이성, 확장성, 품질관리 용이)
  • AOP : 트랜잭션, 로깅, 보안과 같이 여러 모듈에서공통적으로 사용하는 기능의 경우 해당 기능을 공통 모듈로 분리하여 관리한다.(프로그램 가독성, 기술 은닉)
• O/R 매핑 프레임워크 지원
  데이터베이스 라이브러리와 연결할 수 있는 인터페이스를 제공(Mybatis, Hibernate, JPA)
• 스프링 데이터를 통한 다양한 데이터 연동 기능
  NoSQL DB유형(문서형, 그래프형, 키-값 구조형, 컬럼형)의 데이터 저장소 및 검색 엔진 연동
• 스프링 배치
  대량의 데이터를 일괄 처리ㅡ 병행 처리할 수 있는 템플릿 제공