Spring 용어 정리

1. JSP Model1, Model2, Spring MVC pattern 차이

MVC 패턴이란 Model, View, Controller 의 합성어로 소프트웨어 공학에서 사용되는 소프트웨어 디자인 패턴이다.

Model : DB와 상호작용하여 비즈니스 로직을 처리하는 모듈 , 백그라운드에서 동작하는 로직을 처리
View : Client에게 보여지는 결과화면을 반환하는 모듈, 사용자가 보게 될 결과 화면을 출력
Controller : client 요청이 들어왔을 때 그 입력을 처리하고 어떤 로직을 실행시킬 것인지 제어하는 모듈, 사용자의 입력처리와 흐름 제어를 담당

이는 웹개발 하면 필수적으로 알아야 할 디자인 패턴으로 MVC패턴에는 Model1 방식과 Model2 방식이 있다. 간단하게 분류하자면 Model1은 출력과 로직을 JSP에서 전부 처리하고 Model2는 JSP에서 출력만 처리한다.

• Model 1
  view와 logic을 모두 JSP 페이지 하나에서 처리하는 구조를 말한다. Model1을 구성하는 요소는 크게 두 가지로 나뉘는데;

1. JSP
2. JavaBean 혹은 service class

JSP 페이지 내에 로직 처리를 위한 자바 코드가 출력을 위한 코드와 함께 섞여 삽입된다. 브라우져에서 요청이 들어오면 JSP 페이지는 자신이 직접 자바빈이나 따로 작성한 서비스 클래스를 이용하여 작업을 처리하고 그 처리한 정보를 클라이언트에 출력한다.

* 장점 : 구조가 단순하여 익히기가 쉽다. 때문에 숙련된 개발자가 아니더라도 구현이 용이하다.
* 단점 : 출력을 위한 뷰 코드와 로직 처리를 위한 자바 코드가 함께 섞이기 때문에 JSP 코드 자체가 복잡해진다.
		JSP 코드에서 백앤드와 프론트앤드가 혼재되기 때문에 분업이 용이하지 않다.
        코드가 복잡해져 유지보수가 어렵다.
        
        

• Model 2
  Model2는 모든 처리를 JSP 페이지 하나가 담당하는 Model1과 달리 JSP 페이지와 servlet, 그리고 로직을 위한 클래스가 나뉘어 브라우저 요청을 처리한다. Model2를 구성하는 요소에는;

1. Servlet
2. JSP
3. 자바빈 혹은 서비스 클래스

요청이 들어오면 요청에 대한 로직 처리는 이를 처리할 모델(Model)인 Service class 혹은 Javabean이 담당하고, 요청 결과는 유저에게 결과를 보여줄 View인 JSP에 출력되며, 이를 위한 모든 흐름 제어를 controller인 servlet이 담당한다.

* 장점 : 출력을 위한 뷰 코드와 로직 처리를 위한 자바 코드를 분리하기 때문에 JSP 모델1에 비해 코드가 복잡하지 않다.
		뷰, 로직 처리에 대한 분업이 용이하다.
        기능에 따라 분리되어 있기 때문에 유지보수가 용이하다.
        
* 단점 : 구조가 복잡하여 습득이 어렵고 작업량이 많다.
		JAVA에 대한 깊은 이해가 필요하다, 
    

• Spring MVC Model
  Spring MVC는 Model2 방식을 따르며 이 Model2의 architecture에 맞게 설계되어 있다.

1. DispatcherServlet이 Client의 요청을 받는다. (중앙 제어실과 같다)
2. HandlerMapping이 알맞은 Controller를 찾는다.
3. HandlerMapping에 실행할 Controller의 method를 찾는다.
4. Controller의 method를 실행하며 그 결과 Model로서 DispatcherServlet에 반환한다.
5. ViewResolver는 알맞은 JSP 파일을 찾는다.
6. View는 JSP 파일을 Model의 정보를 토대로 Client에게 반환한다.

• 모델2가 무조건 장점만 가지고 있는 것은 아니다. 모델 2는 규모가 큰 프로젝트나 업데이터가 빈번한 프로젝트에선 용이하지만 규모가 많이 크지 않고 업데이트가 적은 프로젝트일 경우엔 복잡한 형태로 작업량이 늘어날 뿐이다. 이 경우에는 모델 1으로 개발하는 것이 나을 수도 있다.

2. Spring framework /Spring boot

• Spring framework
  spring framework에 대해 이해하기 위해서는 프레임워크가 무엇인지, 라이브러리와의 차이가 어떤건지 알고 있는게 중요하다.
  라이브러리는 간단하게 특정기능을 하는 코드 뭉치라고 볼 수 있다. 개발자는 자기 코드에 라이브러리를 포함시키고 원하는 기능을 사용해서 개발할 수 있다. 즉, 원하는 기능을 하는 함수를 콜해서 사용한다.
  프레임워크는 라이브러리를 포함하는 개념이고, 개발자가 만든 코드를 사용한다. 코드를 어떻게 실행하는지는 코드를 사용하는 프레임워크에 따라 다르다.

스프링 프레임워크는 자바 플랫폼을 위한 오픈소스 어플리케이션 프레임워크로 여러 라이브러리를 제공하고, 그것을 활용하여 개발한 프로그램을 동작시킨다. 대한민국 공공기관의 웹 서비스 개발 시 사용을 권장하는 전자정부 표준프레임워크의 기반 기술이다.

개발자가 코드 안에 어플리케이션 동작에 대한 내용을 기술하면 스프링 프레임워크가 이를 해석 동작한다.

* Sprnig 특징
1. 경량 컨테이너로서 자바 객체를 직접 관리
	각각의 객체 생성, 삭제와 같은 라이프 사이클을 관리하며 스프링으로부터 필요한 객체를 얻어올 수 있다.
2. 제어 역행 (IoC : Inversion of Control) 

3. 의존성 주입 (DI : Dependency Injection)
4. 관점지향 프로그래밍 (AOP : Aspect-Oriented Programming)
5. 어플리케이션 객체의 생명 주기와 설정을 포함하고 관리한다는 점에서 일종의 "컨테이너"라고 할 수 있다.
iBatis, myBatis 나 Hibernate 등 완성도 높은 데이터베이스처리 라이브러리와 연결할 수 있는 라이브러리 제공
6. Transaction 관리 프레임워크
추상화된 트랜잭션 관리를 지원하며 설정파일(xml, java, property 등)을 이용한 선언적인 방식 및 프로그래밍을 통한 방식을 모두 지원한다.
7. model - view - controller pattern
웹 프로그래밍 개발 시 거의 표준적인 방식인 "Spring MVC"라 불리는 MVC 패턴을 사용
DispatcherServlet이 Controller 역할을 담당하여 각종 요청을 적절한 서비스에 분산시켜주며 이를 각 서비스들이 처리를 하여 결과를 생성하고 그 결과는 다양한 형식의 View 서비스들로 화면에 표시될 수 있다.
8. 배치 프레임워크
스프링은 특정 시간대에 실행하거나 대용량의 자료를 처리하는데 쓰이는 일괄 처리 (Batch Processing)을 지원하는 배치 프레임워크를 제공한다. 기본적으로 스프링 배치는 Quartz 기반으로 동작한다.
9. 즉 공통 부분의 소스 코딩이 용이하며 확장성도 매우 높다.

• Spring Boot
  spring framework는 기능이 많지만 환경설정이 복잡하다. 이를 보완하기 위해 나온 것이 spring boot이다. spring boot는 spring framework를 사용하기 위한 설정의 많은 부분을 자동화하여 사용자가 편하게 스프링을 사용할 수 있게 한다. 실행환경이나 의존성 관리 등의 인프라 관련 등을 신경쓰지 않고 바로 코딩을 시작할 수 있다.

스프링 부트는 코드 생성 프레임워크가 아니기 때문에 코드를 생성하지 않는다. 또한 어플리케이션 sub도, 웹서버도 아니다. 다양한 어플리케이션, 웹서버와의 통합을 제공한다. 스프링 부트는 특정 프레임워크나 스펙을 구현하지 않는다.

* 스프링 부트의 목표:
1. 스프링-기반 프로젝트를 신속히 구축할 수 있다.
2. 일반적인 사용법에 따라 기본적인 가정을 만든다. 기본 값과의 차이를 처리하는 구성 옵션을 제공한다. 
3. 다양한 비기능적인 특징을 제공한다.
4. 코드 생성을 사용하지 않고, 많은 XML 구성을 피할 수 있다.

3. POJO (Plain Old Java Object)

POJO는 직역하여 평범한 구식 자바 오프젝트이다. 무거운 EJB(Enterprise JavaBean) 와는 반대로 경량의 자바 객체를 강조하는 의미로 사용했다. Java EE 등의 중량 프레임워크들을 사용하게 되면서 해당 프레임워크에 종속된 '무거운' 객체를 만들게 된 것에 반발하여 사용하게 된 용어이다.

- POJO 개념을 사용하지 않은 예시 (특정 환경에 결합도가 높은 코드)
JSM로부터 메시지를 받는 경우 MessageListener 인터페이스를 상속받아야한다.

위와 같이 구현하면 JMS라는 특정 환경에 종속하게 되고 다른 메시징 솔루션 적용이 어렵다.

- POJO 개념을 사용한 예시 ( 특정 환경에 결합도가 낮은 코드)
어떠한 인터페이스에 종속되지 않는다.

위는 @JmsListenr라는 어노테이션을 사용하여 JMS 서비스와 연동한다. 다른 솔루션을 이용하고자 하면, @RabbitListener로 바꿔주기만 하면 된다.

• POJO의 조건

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

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

   3. 단일 책임 원칙을 지키는 클래스

   즉, POJO란 객체지향적인 원리에 충실하면서, 특정환경과 규약에 종속되지 않아 필요에 따라 재사용될 수 있는 방식으로 설계된 오브젝트라고 할 수 있다.

3. IoC (Inversion of Control : 제어의 역전)
   제어의 역전 이라는 의미는 외부에서 결정되는 것을 말한다. 즉, 외부(컨테이너)에서 제어한다.

제어의 역전 개념은 이미 폭넓게 적용되어 있는데, 일반적으로 자바 프로그램은 main() method에서 시작해서 개발자가 미리 정한 순서를 따라 객체가 생성되고 실행된다.
그런데 Servlet을 생각해보면, Servlet을 개발해서 서버에 배포할 수는 있지만, 배포하고 나서 개발자가 직접 제어 할 수 있는 방법은 없다. 대신 서블릿에 대한 제어 권한을 가진 컨테이너가 적절한 시점에서 서블릿 클래스의 객체를 만들고 그 안의 메소드를 호출한다.

이 방식은 대부분의 프레임워크에서 사용하는 방법으로, 개발자는 필요한 부분을 개발해서 끼워 넣기의 형태로 개발하고 실행하게 된다. 프레임워크가 이러한 구조를 가지기 때문에, 개발자는 프레임워크에 필요한 부품을 개발하고, 조립하는 방식의 개발을 하게 된다.

이렇게 조립된 코드의 최종 호출은 개발자에 의해서 제어되는 것이 아닌 프레임 워크의 내부에서 결정된 대로 이뤄지게 된다. 이러한 현상을 "IoC"라고 표현한다.

* IoC Container

5. DI(Dependency Injection : 의존성 주입) (3 type)
   객체 자체가 아니라 Framework에 의해 객체의 의존성이 주입되는 설계 패턴

- Framework에 의해 동적으로 주입되므로 여러 객체 간의 결합이 줄어든다. 
- Dependency Injection은 Spring Framework에서 지원하는 IoC의 형태
- Container가 bean 객체를 생성하고 종속성 주입을 수행한다.
- Dependency Injection과 Inversion Of Control은 같은 의미로 사용된다. : IoC는 DI를 통해 달성된다.

1. Contructor Injection : 생성자를 통한 전달
	<constructor-arg ref="cat"></constructor-arg>
2. Method(Setter) Injection : setter()을 통한 전달
	<property name="myName" value="poodle"></property>
3. Field Injection : 멤버 변수를 통한 전달

*장점

- Reduced Dependencies
- 종속성이 감소한다
- components의 종속성이 감소하면 변경에 민감하지 않다.
- More Reusable Code
- 재사용성이 증가한다.
- 일부 인터페이스의 다른 구현이 필요한 경우, 코드를 변경할 필요없이 해당 구현을 사용하도록 components를 구성할 수 있다.
- More Testable Code
- 더 많은 테스트 코드를 만들 수 있다.
- Mock 객체는 실제 구현의 테스트로 사용되는 객체
- 종속성을 components에 주입할 수 있는 경우 이러한 종속성의 Mock 구현을 주입할 수 있다.
- 예를 들어, Mock 객체가 올바른 객체를 반환할 때, null을 반환할 때, 예외가 발생할 때 모두 처리한다.
- More Readable Code
- 코드를 읽기 쉬워진다.
- components의 종속성을 보다 쉽게 파악할 수 있으므로 코드를 쉽게 읽을 수 있다.

6. AOP (Aspect Oriented Programming : 관점 지향 프로그래밍)
   AOP는 관점 지향 프로그래밍으로, 어떤 로직을 기준으로 핵심적인 관점, 부가적인 관점으로 나누어서 보고 그 관점을 기준으로 각각 모듈화하겠다는 것이다. (모듈화는 어떤 공통된 로직이나 기능을 하나의 단위로 묶는 것을 말한다)

예를 들어 핵심적인 관점은 우리가 적용하고자 하는 핵심 비즈니스 로직이 되고, 부가적인 관점은 핵심 로직을 실행하기 위해서 행해지는 데이터베이스 연결, 로깅, 파일 입출력 등이 된다.

AOP에서 각 관점을 기준으로 로직을 모듈화한다는 것은 코드들을 부분적으로 나누어서 모듈화하겠다는 의미다. 이때, 코드상에서 다른 부분에서 계속 반복해서 쓰는 코드들을 Crosscutting Concerns (흩어진 관심사) 라고 부른다.

위와 같이 Crosscutting Concerns를 Aspect로 모듈화하고 핵심적인 비즈니서 로직에서 분리하여 재사용하겠다는 것이 AOP의 취지이다.

* AOP 주요 개녕
- Aspect : Crosscutting Concerns를 모율화 한 것. 주로 부가기능을 모듈화함
- Target : Aspect를 적용하는 곳 (Class, method, ...)
- Advice : 실질적으로 어떤 일을 해야할 지에 대한 것, 실질적인 부가기능을 담은 구현체
- JointPoint : Advice가 적용될 위치, 끼어들 수 있는 지점, 메서드 진입 지점, 생성자 호출 시점, 필드에서 값을 꺼내올 때 등 다양한 시점에 적용가능
- PointCut : JointPoint의 상세한 스펙을 정의한 것. 'A란 method의 진입 시점에 호출할 것' 같이 더욱 구체적으로 Advice가 실행될 지점을 정할 수 있댜


* Spring AOP 특징
- 프록시 패턴 기반의 AOP 구현체, 프록시 객체를 쓰는 이유는 접근 제어 및 부가기능을 추가하기 위해서이다.
- 스프링 빈에만 AOP를 적용 가능하다.
- 모든 AOP 기능을 제공하는 것이 아닌 스프링 IoC와 연동하여 엔터프라이즈 어플리케이션에서 가장 흔한 문제에 대한 해결책을 지원하는 것이 목적이다.


* Spring AOP : @AOP
스프링 @AOP를 사용하기 위해 다음과 같은 dependency를 추가해야 한다.

다음에는 @Aspect 어노테이션을 붙여 이 클래스가 Aspect를 나타내는 클래스라는 것을 명시하고 @Component를 붙여 스프링 빈으로 등록한다.

@Around 어노테이션은 target method를 감싸서 특정 Advice를 실행한다는 의미이다. 위 코드의 Advice는 target metho가 실행된 시간을 측정하기 의한 로직을 구현하였다. 추가적으로 execution가 의미하는 바는 com.saelobi 아래의 패키지 경로의 EventService 객체의 모든 메서드에 이 Aspect를 적용하겠다는 의미이다. 
(출처: https://engkimbs.tistory.com/746)


*Aspect 실행 시점을 지정하는 어노테이션
- @Around
- @Before : 어드바이스 타겟 메소드가 호출되기 전에 어드바이스 기능을 수행
- @After : 타겟 메소드의 결과에 관계없이 타겟 메소드가 완료되면 어드바이스 기능을 수행
- @AfterReturning : 타겟 메소드가 성공적으로 결과값을 반환 후에 어드바이스 기능을 수행
- @AfterThrowing : 타겟 메소드가 수행 중 예외를 던지게 되면 어드마이스 기능을 수행
- @Around : 어드바이스가 타겟 메소드를 감싸서 타겟 메소드 호출 전과 후에 어드바이스 기능을 수행

7. DTO (Data Transfer Object)
   DTO는 계층 간 데이터 교환을 위한 자바빈즈를 말한다. 여기서 말하는 계층은 Controller, View, Business Layer, Persistent Layer를 말하며 각 계층 간의 데이터 교환을 위한 객체를 DTO 또는 VO라고 부른다. (VO는 DTO와 동일한 개념이지만 read only 속성을 가짐)

일반적인 DTO는 로직을 갖고 있지 않는 순수한 데이터 객체이며 속성과 그 속성에 접근하기 위한 getter, setter 메소드만 가진 클래스를 말한다.

* DTO class 예제

8. DAO (Data Access Object)
   DAO는 Database의 data에 접근을 위한 객체이다. Database에 접근을 하기 위한 로직과 비즈니스 로직을 분리하기 위해 사용한다. DAO의 경우는 DB와 연결할 Connection까지 설정되어 있는 경우가 많다. 그래서 현재 많이 쓰이는 Mybatis등을 사용할 경우 커넥션풀까지 제공되고 있기 때문에 DAO를 별도로 만드는 경우는 드물다.

일반적으로 한 개의 DB 테이블 당 한 개의 DAO 클래스를 작성한다. 각 DAO 클래스는 INSERT, SELECT, UPDATE, DELETE query를 실행해 주는 메소드를 제공한다.
DAO클래스는 테이블로부터 데이터를 읽어와 자바 객체로 변환하거나 또는 자바 객체의 값을 테이블에 저장해주므로, 테이블의 칼럼과 매핑되는 property를 갖는 자바 클래스를 작성해줘야 한다.

* DAO에서 Connection에 접근하는 방식
DAO가 쿼리를 실행하기 위해 statement나 PreparedStatement가 필요한데 이 두 객체는 Connection 객체로부터 구할 수 있다.

- DAO 클래스 메서드에서 직접 Connextion 생성

method 실행시 매번 connection 생성 (두 개를 호출하는데 커넥션이 두번 생기는 문제가 있다. jdbc 기반의 트랜젝션은 한 개의 커넥션에서만 유효하다)
- DAO 객체를 생성할 때 생성자에서 Connection을 전달받기
하나의 connection 객체를 사용하지만 매번 새로운 DAO 객체를 생성해야 한다.
- DAO 클래스의 method parameter로 Connection을 전달받기
한개의 connection을 상용하고 매번 DAO 객체를 생성하지 않아도 되지만 method를 실행할 때마다 connection을 parameter로 전달해줘야 한다.

* DAO Class 예제