Spring Web 계층

위 사진이 Spring Web 계층을 한 사진안에 담은 것이다.

이전에 설명했던 DTO, DAO, VO, Entity나 MVC 패턴 같은 것은 따로 설명하지 않고 Spring Web 계층 자체에 대해서만 집중하여 설명하도록 하겠다.

---

Web Layer

Presentation Layer라고도 한다.

브라우저에서 Web Client의 Request를 처리하거나 Respond를 보내는 역할을 수행하는 Layer이다.

 

또한 Service Layer나 Repository Layer에서 Exception이 발생할 경우 최종적으로 이 Web Layer에서 해당 Excpetion을 처리하게 된다.

 

자 Web Layer가 Request와 Respond를 처리하는, 외부 요청 및 응답에 대한 로직을 처리한 Layer라는 것을 알 수 있다. 그렇다면 이를 Spring에서는 어디에서 처리할까?

 

바로 @Controller 어노테이션을 활용한 Controller 클래스가 이 계층에 속한다.

Controller 클래스는 URI 및 HTTP Method를 포함시켜 각각의 메소드를 생성한다. 컨트롤러 클래스의 1개의 메서드는 곧 1개의 Web Site, 혹은 1개의 Transaction 로직 처리 Site라고 생각할 수 있을 것이다.

 

여기에서는 데이터를 보내거나 받을 때 RequestDTO, ResponseDTO를 활용하기 때문에 DTO만 활용되는 Layer라는 것을 파악할 수 있다.

---

Service Layer(Business Layer)

Application 핵심 로직을 담당하며 전달 받은 데이터가 설정한 Entity 형식과 일치하는지 확인하는 역할을 수행한다.

Presentation Layer와 Data Access Layer 사이를 연결하는 역할로써 Controller로 데이터를 받은 이후 바로 데이터를 처리하지 않고 중간 계층을 통해 데이터를 처리함으로써 더욱 깔끔하고 객체 지향적인 개발을 수행할 수 있게 해주는 Layer이다. 또한 Transaction을 담당하여 여러 번 DB에 접속하여 Logic을 처리할 수 있게 해주는 주체가 되기도 한다.

 

또한 Service Layer를 활용하면 중복코드를 줄일 수 있고 재사용성이 증가한다는 특징이 존재한다.

Service Layer는 결국 "트랜잭션의 메서드화"라고 할 수 있다. 1개의 메서드마다 내가 원하는 트랜잭션에 대한 로직을 짜주는 것이다.

 

만약 Controller의 A 메서드는 (데이터 수정 + 데이터 조회)를 원하고 Controller B 메서드는 (데이터 수정 + 데이터 생성)을 원한다고 가정하자.

이 때 A와 B는 "데이터 수정"이라는 공통된 로직을 가지는데 만약 Service Layer를 활용하지 않을 경우 데이터 수정에 대한 공통된 로직이 다른 메서드에 포함되고, 이는 중복된 코드를 발생시킬 것이다.

그렇다고 이 중복된 코드를 Controller의 새로운 메서드로 만들기에는 Controller의 "Request를 처리하거나 Respond를 보내는 클래스"라는 정의를 무시해버리는 코드가 될 것이다.

이 때 Service Layer에 데이터 수정 U 메서드, 데이터 조회 S 메서드, 데이터 생성 C 메서드를 입력하면 A 메서드에서는 (U+S), B 메서드는 (U+C)로 로직을 구현하여 코드의 중복 없이 U 메서드를 재사용하여 훨씬 빠르고 쉬운 코딩이 가능해지는 것이다.

 

Spring에서는 @Service 어노테이션을 활용한 Service 구현 클래스가 이 계층에 속한다.

 

이 Service Layer는 먼저 Controller에서 DTO를 전달받는다. 이후 이 DTO를 Entity로 변환하는 과정이 수행된다.

만약 Entity로 변환하는 과정에서 에러가 발생하면 DTO가 잘못된 데이터를 전달했다는 것이며 이를 다시 Controller측에 예외 처리를 수행하라고 요청을 보낸다. 즉, 데이터가 Entity 형식과 맞는지를 판단하는 역할을 수행해주는 것이다.

 

Entity 형식과 일치했다고 가정하자. 그렇다면 DTO가 Entity로 바뀌고 드디어 DB에 접속할 수 있을 것이다.

하지만 직접 DB에 접속하여 Query를 수행하는 역할은 Data Access Layer에서 처리한다. 즉 Service Layer는 Data Access Layer에 미리 구현해 놓은 Query들을 적절하게 처리하여 1개의 Transaction을 만들고 이를 수행하게 된다.

내가 팀 A와 팀 B를 동시에 저장할 경우 팀을 저장하는 Query 자체는 Data Access Layer측에 만들어져 있고 Service Layer는 이 Query를 사용하여 팀 A와 팀 B가 한번에 저장될 수 있도록 Transaction을 짜는 로직이 구현되는 것이다.

 

이 서비스 계층은 "트랜잭션"을 관리하기 때문에 가장 중요한 점은 DB의 트랜잭션의 특징을 가져야하는 것이다. 아마 그 중 가장 중요한 특성은 All or Nothing으로 Transaction 전체를 DB에 적용하거나 중간에 에러가 발생했을 경우에는 1개도 적용되서는 안된다.

이런 특성을 적용해주기 위하여 Service 클래스는 @Transactional 어노테이션을 활용하여 All Or Nothing이라는 특징을 지키도록 노력한다

 

DTO를 Entity로 바꾸어 Data Access Layer로 전달하는 계층이므로 유일하게 DTO와 Entity가 동시에 활용되는 계층이다.

---

Data Access Layer

이전에 배웠던 MyBatis나 JPA가 실제로 활용되는 계층이다.

실제로는 DAO를 활용하지만 이전에 말했듯 Spring에서는 직접 DAO를 활용한다기 보다는 Spring Data JPA의 JpaRepository를 활용하거나 MyBatis의 Mapper 인터페이스를 활용한다. 이렇게 Interface를 생성하면 Spring 측에서 알아서 DAO 구현 클래스를 만들어주고 원하는 메서드에 맞는 적절한 Query를 구현하여 적용할 것이다.

 

직접 DB에 접속하여 CRUD 로직을 수행하는, Table 상태를 변경시키는 계층이라고 말할 수 있다.

 

Spring에서는 직접 DB에 접속할 수 있는 객체는 Entity 객체밖에 없으므로 Entity 객체만 활용되는 Layer이다.

 

* Domain Model Layer : 사실 Layer라고 하기에도 애매하다. 그냥 DB Table에 매칭될 클래스로 Entity 클래스를 의미한다.