➡️DAO 란?

• Data Access Object의 약자로 실제로 DB에 접근하는 객체이다.
• 서비스와 DB를 연결하는 역할을 한다.
• SQL을 사용하여 DB에 접근한 후 적절한 CRUD API를 제공한다.(ex:JPA)

➡️DTO 란?

• Data Transfer Object 의 약자로 계층간 데이터 교환을 위한 객체이다.
  • DB에서 데이터를 얻어 서비스나 컨트롤러 등으로 보낼 때 사용하는 객체를 말한다.
  • 로직을 갖고 있지 않은 순수한 데이터 객체이며,getter/setter메서드만 갖는다.
  • 그러나 DB에서 꺼낸 값을 임의로 변경 할 필요가 없기 때문에 DTO클래스에는 setter가 없다 그대신 생성자에서 값을 할당한다.
• Request와 Response용 DTO는 View를 위한 클래스이다.
  • 자주 변경이 필요한 클래스
  • toEntity메서드를 통해서 DTO에서 필요한 부분을 이용하여 Entity로 만든다.

➡️Entity Class 란?

• 실제 DB 테이블과 매칭될 클래스이다.
  • @Entity,@Column,@Id 사용
• 최대한 외부에서 Entity클래스의 getter method를 사용하지 않도록 해당 클래스 안에서 필요한 로직 메서드를 구현한다.
  • 도메인 로직만 가지고 있어야 하고 프레젠테이션 로직을 가지고 있으면 안된다.

➡️Entity Class 와 DTO를 분리하는 이유

• View Layer과 DB Layer의 역할을 확실하게 분리하기 위해서 분리한다.
• 테이블과 매핑되는 Entity클래스가 변경되면 여러 클래스에 영향을 끼친다, 그러나 View와 통신하는 DTO클래스는 자주 변경되므로 분리하여야 한다.
• DTO는 도메인 모델을 복사한 형태로 다양한 프레젠테이션로직을 추가한 정도로 사용하며 도메인 모델 객체는 persistent만을 위해서 사용한다.

=>예시

REFERENCE

• https://gmlwjd9405.github.io/2018/12/25/difference-dao-dto-entity.html

📡프록시란?

• 프록시란 프로토콜에 있어서 대리 응답 등에사 사용하는 개념이다. 보안상의 문제로 직접 통신을 주고 받을 수 없는 사이에서 프록시를 이용해서 중계를 하는 개념이다.
• 이렇게 중계 기능을 하는 것을 프록시 서버[Proxy Server]라고 한다.

📡프록시 서버 특징

프록시 서버는 클라이언트와 서버의 입장에서 볼 때 서로 반대의 역할을 하는 것처럼 보여지게 된다.

클라이언트가 프록시를 바라보면 프록시가 서버처럼 동작 하는것이고, 서버가 프록시를 바라보면 프록시가 클라이언트처럼 동작하는 것처럼 보인다.

프록시를 사용하는 이유에는 보안도 있지만 보안말고도 다른 이유도 있다. 프록시는 프록시 서버에 요청이 된 내용들을 캐시에 저장해둔다.캐시로 저장을 해둔다면 다시 데이터를 가져올 상황이 발생을 하지 않기 때문에 전송 시간을 절약 할 수 있다.

📡프록시 서버는 서버의 위치에 따라 크게 두가지로 나눠 진다.

1.Forward Proxy

특정 사이트를 가려고 할 때, 가고 싶은 목적지 사이트의 주소를 직접 프록시 서버에 전달하여 프록시 서버가 해당 목적지 사이트의 내용을 받아와서 전달을 해주는 개념이다.말 그대로 대신 처리 해주는 역할을 한다.

캐싱 기능이 있으므로 자주 사용되는 컨텐츠들이라면 성능 향상을 가져올 수 있으며,프록시에서 특정 사이트는 접근이 불가능 하도록 제한을 걸 수도 있기 때문에 기업환경에서 많이 사용된다.

2.Reverse Proxy

사용자가 Reverse Proxy로 설정된 서버의 주소로 데이터를 요청하게 되며,프록시 서버가 이 요청을 받아서 실제 내부 서버에서 데이터를 받아와 클라이언트에게 전달을 해 주는 개념 입니다.

이렇게 프록시를 구성하는 이유는 보안 때문이다.

기업 네트워크 환경은 DMZ라고 하는 내부 네트워크와 외부 네트워크 사이에 위치하는 구간이 존재하며,이 구간에는 메일,웹,FTP서버등 외부 서비스를 제공한 서버들이 위치를 하고 있다.

기업이 특정 서비스를 만들어서  WAS서버를 DMZ쪽에 놓고 다이렉트로 사용을 해도 되지만, 대부분의 WAS서버는 DB서버와도 함께 연동 되어 있기 때문에 WAS가 털린다면 DB도 날아간다.

이러한 문제 때문에 Reverse Proxy를 두고 실제 서비스는 내부에 위치 시키고 프록시 서버가 내부 서버와 통신해서 데이터를 받아오는 형식을 사용한다.

📡Reverse Proxy 장점

• 보안 
• 속도와 안정성
• 신뢰성 증대

요청이 들어오면 특정 메서드와 요청하기 위해 사용하는 것이 @RequestMapping이다.

@RequestMapping에서 가장 많이 사용하는 것은 value와 method 이다.

• value는 요청 받을 url을 설정할 수 있다.
• method는 어떤 요청을 받을지 정의한다.(GET,POST,DELETE,PUT,PATCH 등 )

/v1 url로 매핑하는 예제

이렇게 /v1 GET,POST,DELETE,PUT,PATCH 으로  만들수 있다.

그러나 눈에 확 들어오지 않고 조금 반복적인 코드가 많이 발생한다.

조금 더 효율적이고 간단한 코드를 한번 보자

이렇게 바꿀수 있다. 확실히 전 코드 보다는 간략하고 눈에 더 잘들어 온다.

그러나 여기서 보면  "/v1"이 중복되는걸 조금 수정하고 싶어진다.

클래스 레벨에서 중복되는 url주소를 적으면 중복되는 코드를 조금이나마 줄일수 있다.

이런식으로 클래스 레벨에 등록하면 중복되는 url경로도 줄일 수 있다.

그리고 GetMapping에 보면 ("/cont")가 있다. 그렇다면 이 경로는 "/v1/cont"로 요청된다.

@RequestMapping은 클래스와 메소드에 붙일 수 있고, @GetMapiing,@PostMapping,@PutMapping,@DeleteMapping,@PatchMapping은 메소드에만 붙일 수 있고 클래스 레벨에는 붙일 수 없다.

이런식으로 어노테이션으로 중복되는 코드를 줄이고 효율적인 코드를 작성 할 수 있다.

데이터베이스

• 데이터베이스는 조직에 필요한 정보를 얻기 위해 논리적으로 연관된 데이터를 모아 구조적으로 통합해 놓은 것이다.

데이터베이스 시스템

• 데이터베이스 시스템은  데이터의 검색과 변경을 주로 한다.
• 변경이란 시간에 따라 변하는 데이터 값을 데이터베이스에 반영하기 위해 수행하는 삽입(insert),삭제(delete),수정(update) 등의 작업을 말한다.
• 검색과 변경의 빈도에 따라 시스템 구축의 난이도가 결정된다.

데이터 베이스 시스템 개념 및 특징

개념

1.통합된 데이터(integrated data)

• 여러 곳에서 사용하던 데이터를 통합하여 하나로 저장한 데이터를 의미한다.
• 통합 시 중요한 점은 각각 사용하던 데이터의 중복을 최소화함으로써 중복 저장으로 인한 데이터 불일치 현상을 없애는 것이다.

2. 저장된데이터(store data)

• 문서로 보관된 데이터가 아니라 디스크,테이프 같은 컴퓨터 저장장치에 저장된 데이터를 의미한다.

3.운영 데이터(operational data)

• 조직의 목적을 위해 사용되는 데이터를 의미한다.

4.공용 데이터(shared data)

• 한 사람 또는 한 업무를 위해 사용되는 데이터가 아니라 공동으로 사용되는 데이터를 의미한다.

특징

1. 실시간 접근성

• 실시간이란 사용자가 요청하는 순간에 실제 데이터를 서비스 하는 것을 말한다.

2. 계속적인 변화

• 데이터베이스에 저장된 내용은 어느 한 순간의 상태를 나타내지만, 데이터 값은 시간에 따라 항상 바뀐다.

3. 동시 공유

• 데이터베이스는 서로 다른 업무 또는 여러 사용자에게 동시에 공유된다.

4. 내용에 따른 참조

• 데이터베이스에 저장된 데이터는 데이터의 물리적인 위치가 아니라 데이터 값에 따라 참조된다.

=> 정답률이 낮은 편이다. 최대 공약수를 구하는 방법과 유클리드 호제법을 알아야 풀기가 조금은 수월할거같다.

➡️Entity Manager Factory & Entity Manager

 Entity Manager Factory를 이용해서 Entity Manager 생성이 가능하다. Entity Manager Factory 는 비용이 많이 소요되기 때문에 하나의 애플리케이션에서 공유해서 사용이 가능하고, 멀티스레드에서도 동기화 처리를 통해 안전하게 사용이 가능하다. 하지만 Entity Manager는 여러 스레드에서 공유해서 사용되서는 안되기 때문에 스레드마다 Entity Manager를 생성할 필요가 있다.

JPA Database 설정 properties

➡️영속성 컨텍스트 

JPA에서 가장 중요한 영속성 컨텍스트는 엔티티를 영구 저장하는 환경이라는 뜻이다. 엔티티 매니저를 생성하면 영속성 컨텍스트가 자동으로 생성되고, Entity Manager를 이용해서 영속성 컨텍스트에 엔티티를 보관/관리한다.

영속성 컨텍스트의 특징

• 엔티티 매니저를 생성할 때 하나 만들어진다.
• 엔티티 매니저를 통해서 영속성 컨텍스트에 접근하고 관리할 수 있다.

엔티티는 4가지 속성을 가지고 있다.

비영속(new/transient): 엔티티 객체를 생성했지만 아직 영속성 컨텍스트에 저장하지 않은 상태를 비영속이라고 한다.

• 준영속 상태의 엔티티는 영속성 컨텍스트가 제공하는 기능을 사용할 수 없다.식별자 값을 가지고 있다.

➡️영속성 컨텍스트 특징

영속성 컨텍스트의 식별자 값

 => 영속성 컨텍스트는 엔티티를 식별자 값으로 구분한다. 따라서 영속 상태는 식별자 값이 반드시 있어야 한다.

영속성 컨텍스트와 데이터베이스 저장 

 =>JPA는 보통 트랜잭션을 커밋하는 순간 영속성 컨텍스트에 새로 저장된 엔티티를 데이터 베이스에 반영하는데 이를 flush라 한다.

1. 1차 캐시

영속성 컨텍스트 내부에는 캐시가 있는데 이를 1차 캐시라고 한다. 영속 상태의 엔티티를 이곳에 저장한다. 1차 캐시의 키는 식별자 값(데이터베이스의 기본 키)이고 값은 엔티티 인스턴스이다.

조회 

2. 동일성 보장

3. 트랜잭션을 지원하는 쓰기지연 

em.find(member)를 사용해 member를 저장해도 바로 INSERT SQL이 DB에 보내지는 것이 아니다. 엔티티 매니저는 트랜잭션을 커밋하기 직전까지 내부 쿼리 저장소에 INSERT SQL을 모아둔다. 그리고 트랜잭션을 커밋할 때 모아둔 쿼리를 DB에 보낸다. 이것을 트랜잭션을 지원하는 쓰기 지연이라 한다. 

4. 변경감지

JPA로 엔티티를 수정할 때는 단순히 엔티티를 조회해서 데이터를 변경하면 된다.

➡️Spring에서 컨트롤러를 지정해주기 위한 어노테이션은 @Controller와 @RestController가 있다.

전통적인 Spring MVC의 컨트롤러인 @Controller와 Restuful 웹서비스의 컨트롤러인 @RestController의 주요한 차이점은 HTTP Response Body가 생성되는 방식에서 나타난다.

➡️@Controller

• SpringMvc 컨트롤러인 @Controller는 주로 View를 반환하기 위해 사용한다.

1. 클라이언트는 URI형식으로 웹 서비스애 요청을 보낸다.
2. DispatcherServlet이 요청을 받아 매핑되는 핸들러와 그 type을 찾아 준다.
3. 다음은 요청한 뷰 이름으로 viewResolver를 찾는다.
4. viewResolver는 뷰의 논리 이름을 물리 이름으로 바꾸고 ,렌더링 역할을 담당하는 뷰 객체를 반환한다.
5. 마지막으로 뷰를 통해서 뷰를 렌더링 한다.
6. 렌더링 한 후에는 뷰를 사용자에게 반환한다.

@Controller를 위 코드처럼 사용한다면 DispatcherServlet이  핸들러 어댑터를 호출한다. 핸들어 어댑터를 통해 members라는  뷰 이름을 획득한다.그리고 뷰를 반환한다.

혹여나 @Controller로 데이터를 반환할려고 한다면 @ResponseBody를 사용해줘야 한다.

@RestController

• RestController는 SpringMvc Controller에 @ResponseBody가 추가된 것이다.
• RestController는 주로 Json 형태로 객체 데이터를 반환하는 것이다.
• RestController는 viewResolver대신에 HttpMessageConverter가 동작한다.

• @Controller 는 반환 값이 String 이면 뷰 이름으로 인식된다. 그래서 뷰를 찾고 뷰가 랜더링 된다.
• @RestController 는 반환 값으로 뷰를 찾는 것이 아니라, HTTP 메시지 바디에 바로 입력한다. 따라서 실행 결과로 get users, post users 메세지를 받을 수 있다.

➡️HttpMessageConverter 간단한 동작 방식

@RestController가 Data를 반환하기 위해서는 viewResolver 대신에 HttpMessageConverter가 동작합니다. HttpMessageConverter에는 여러 Converter가 등록되어 있고, 반환해야 하는 데이터에 따라 사용되는 Converter가 달라진다.

단순 문자열인 경우에는 StringHttpMessageConverter가 사용되고, 객체인 경우에는 MappingJackson2HttpMessageConverter가 사용되며, 데이터 종류에 따라 서로 다른 MessageConverter가 작동하게 된다.

Spring은 클라이언트의 HTTP Accept 헤더와 서버의 컨트롤러 반환 타입 정보 둘을 조합해 적합한 HttpMessageConverter를 선택하여 이를 처리한다. 

• 대표적인 것들이 MappingJackson2HttpMessageConverter, StringHttpMessageConverter가 있다. StringHttpMessageConverter는 요청이 String으로 들어오면 문자로 처리한다.
• MappingJackson2HttpMessageConverter는 요청이 객체 또는 HashMap으로 들어 오면 JSON으로 처리한다.

➡️정리

• @Controller는 데이터를 처리 할 수 있지만 view만 처리하고 @RestController와 분리해서 @Controller는 뷰 처리를 하고 @RestController는 데이터 처리를 분리 해주는 것이 좋을거 같다.
• 일반적은 Spring MVC @Controller와 RESTful 컨트롤러인 @RestController의 차이점은 HTTP Response Body가 생성되는 방식이다.
• @Controller 는 View Page를 반환하지만, @RestController는 객체(VO,DTO)를 반환하기만 하면, 객체데이터는 application/json 형식의 HTTP ResponseBody에 직접 작성되게 된다.

=> 문제가 막 어려운건 아닌데 StringTokenizer의 개념을 모른다면 조금 고민을 할 수도 있을거 같다. 혹시 이해가 잘 안된다면 문자열 카테고리 문제를 풀어보고 오는것도 추천한다.