[도전 기술!] Web Layer

안녕하세요? 주니하랑 입니다.

본 내용은 주니하랑이 Web 개발 프로젝트를 하면서 도전했던 기술들에 대한 내용을 정리하는 곳 입니다!

바로 주니하랑이 정리해서 작성한 것이에요.

주니하랑은 Back End 개발을 맡았었답니다!

---

 

 

🙋 Web Layer를 구성하면서 느낀점

---

국비지원 교육을 받으면서 첫번째 교육이 JAVA Servlet을 이용한 MVC를 이용해서 JSP와 함께 Web Programing을 하는 것이였습니다. 이 때, VO, Controller, DAO, VIEW에 대해 이해를 하였고, 이를 기반으로 Project를 하였습니다.

그런데, Spring Boot를 이용하며, Web Layer의 개념을 이해하려고 하니 자꾸 VO, Controller, DAO, VIEW라는 구분으로 Layer를 이해하려고 하여 이해가 되지 않고, 어렵게 느껴졌습니다.

그러다 보니 비즈니스 로직이라는 단어도 이해가 되지 않았고, 이 기본이 이해가 되지 않다보니 코딩을 하는 것이 어렵게 다가왔습니다.

같이 프로젝트를 하며, BackEnd 팀장이 이것에 대한 좋은 자료를 많이 알려주었고, Googling을 통해 공부를 한 결과 조금씩 이해가 되었고, 이렇게 나누어서 구성을 해야 SoC (Separation of Concerns)의 관심사 분리 원칙과 KISS(Keep It Simple Stupid)라는 간단하고 알기 쉽게 만들자라는 원칙을 지킬 수 있다는 것을 알게 되었고, 아키텍처 디자인을 설계하는데, 지켜야할 기본 원칙이라는 것을 알게 되었습니다.

 

 

🌐 Web Layer

---

• Controller와 View Templat 영역
• Client Request / Respone에 관한 전반적인 영역
  • @Filter, Intercepter, @ControllerAdvice 등

저희가 이번 Project에서 사용했던 Web Layer는 크게 Controller와 Reate를 이용한 View Templat 그리고 Interceptor가 있으며, Controller는 RESTFul하게 구현하기 위하여 REST Controller를 구현하였습니다.

이를 위해 @RestController를 사용하였고, 이것은 Spring MVC Controller에 @ResponseBody가 추가된 것으로 REST Controller는 Json 형태로 Entity Data를 반환 해주는 역할을 합니다.

 

<출처 :  https://mangkyu.tistory.com/49 >

 

• Client는 URI 형식으로 Web Service에 요청
• Mapping 되는 Handler와 Type을 찾는 Dispatcher Servlet이 Request를 Interceptor
• REST Controller는 해당 Request를 처리하고, 결과값 Data 반환

packageudodog.goGetterServer.controller.api.bookreport;

importio.swagger.annotations.*;
importlombok.RequiredArgsConstructor;
importorg.springframework.data.domain.Page;
importorg.springframework.data.domain.Pageable;
importorg.springframework.data.domain.Sort;
importorg.springframework.data.web.PageableDefault;
importorg.springframework.hateoas.EntityModel;
importorg.springframework.http.HttpStatus;
importorg.springframework.http.ResponseEntity;
importorg.springframework.web.bind.annotation.GetMapping;
importorg.springframework.web.bind.annotation.RestController;
importudodog.goGetterServer.model.converter.bookreport.BookReportConverter;
importudodog.goGetterServer.model.dto.DefaultRes;
importudodog.goGetterServer.model.dto.response.bookreport.BookreportResponseDto;
importudodog.goGetterServer.service.bookreport.BookreportService;

@Api(tags = {"독서 기록 관련 API"})
@RestController
@RequiredArgsConstructor
public classBookReportController {

private finalBookReportConverter bookReportConverter;
private finalBookreportService bookreportService;

    @ApiOperation( value = "독서 기록 전체 목록 조회 API", notes = "독서 기록의 전체 목록 조회 API" )
    @ApiResponses( value = {
            @ApiResponse( code=200, message = "1. 조회성공 \t\n 2. 데이터없음 \t\n 3. 토큰에러" )
    })

//전체 조회 관련 Method
@GetMapping("/api/book-reports")
publicResponseEntity<EntityModel<DefaultRes<Page<BookreportResponseDto>>>> totalBookReportFindAll(
            @PageableDefault( sort = "id", direction = Sort.Direction.DESC, size = 10 )Pageablepageable ) {// Index Value를 이용 최신 날짜순을 기준으로 내림차순으로 페이지당 10개씩 출력

return newResponseEntity<>(bookReportConverter.toModel( bookreportService.searchBookReportList(pageable)), HttpStatus.OK);
    }// totalBookReportFindAll()끝

}// Class끝

 

 

🙇‍♂️ Service Layer

---

Client Request에 따른 Data 처리를 하는 계층으로 비즈니스, 트랜잭션 처리를 담당하는 영역으로, 개발 대상을 모든 사람이 동일한 관점에서 이해할 수 있고, 공유할 수 있도록 단순화.

 

📌 BookReportService.Class

@Service
@RequiredArgsConstructor
public class BookreportService {

private finalUserRepositoryuserRepository;
private finalBookReportRepositorybookReportRepository;
private finalBookReportQueryRepository bookReportQueryRepository;

//전체 조회
publicDefaultRes<Page<BookreportResponseDto>> searchBookReportList(Pageablepageable) {//페이징 처리

Page<BookreportResponseDto> bookReportPage = bookReportQueryRepository.findAllWithFetchJoin(pageable);

if(bookReportPage.getTotalElements() == 0) {// bookreport의 내용이 없다면?
returnDefaultRes.response(HttpStatus.OK.value(), "데이터없음");

        }else{// bookreport의 내용이 있다면?
returnDefaultRes.response(HttpStatus.OK.value(), "조회성공", bookReportPage);
        }// if-else끝

}// searchBookReportList()끝

 

🧷 Domain Model

---

Back Ground에서 동작하는 주요 Logic 처리하며, Data를 담당.

보통 Data Base와 직접적인 연관을 맺으며 동작.

 

💨 Entity

---

Data Base Table과 1:1로 Maping되는 Class.

외부에서 무분별한 getter와 setter로 인해 Data의 오염이 발생하면 안되기에 내부 Method로 Data 조작 필요.

저희는 위에서 작성한 Data 오염을 방지하기 위하여 Setter를 제외하고, @Getter와 @Bulder를 통해 Data 주입을 사용하였습니다.

Effective Java 규칙 2 - 조슈아 블로크

생성자에 인자가 많을 때는 빌더 패턴을 고려하라.

빌더 패턴(Builder Pattern)이란 복합 객체의 생성 과정과 표현 방법을 분리하여 동일한 생성 절차에서 서로 다른 표현 결과를 만들 수 있게 해 주는 것입니다.

Builder Pattern을 사용하면 객체들마다 들어가야할 인자가 각각 다를 때 유연하게 사용할 수 있으며, 부분별한 Setter 생성을 방지하고, 불편 객체로 만들 수가 있습니다. 또한, 필수 Argument를 지정할 수 있게 됩니다. (보통의 경우 PK 역할을 할 ID Value) 이렇게 하여 Service와 같은 곳에서 BookReport.builder(). { 여러가지 Field의 초기값 선언 }.build() 형태로 객체를 만들 수 있게 하였습니다.

위의 내용으로 저희는 아래와 같이 코드를 작성하여 Entity를 사용하였습니다.

 

📌 BookReport.java

@Getter
@NoArgsConstructor
@Entity
@EntityListeners(AuditingEntityListener.class)
public class BookReport {

@Id @GeneratedValue(strategy = GenerationType.IDENTITY)
privateLong bookReportId;

@ManyToOne(targetEntity = User.class, fetch = FetchType.LAZY)
@JoinColumn(name = "user_id")
privateUser user;

privateString title;

privateString bookName;

privateString content;

@CreatedDate privateLocalDateTime createdAt;

@Builder
publicBookReport(User user, String title, String bookName, String content) {
this.user = user;
this.title = title;
this.bookName = bookName;
this.content = content;

}//생성자 끝

@ManyToOne은 해당 Entity와 다른 Entity 간에 관계를 짓기 위하여 사용하였습니다.

이것은 Writer 입장에서 BookReport가 여러 개가 될 수 있기 때문에 Writer : BookReport = 1 : N 관계가 되기 때문에 사용 하였습니다.

@Id, @GeneratedValue는 해당 Entity의 주요 키 (Primary Key, PK)가 될 값을 지정하기 위하여 @Id를 사용하였고, @GenneratedValue는 이 PK가 자동으로 1씩 증가하는 형태로 생성될지 등을 결정하기 위해 사용하였습니다.

 

💨 Data Transfer Object

---

Data Transfer Object의 약자, Data 전송 계층 담당.

Data를 Layer(Controller, Service 등) 간 이동 시킬 때 사용.

가능한 Data 전달 이외 기능은 이 곳에 넣지 않음.

계층 간 Data 교환을 위한 Object.

 

📌 BookreportResponseDto.java

@Getter
public class BookreportResponseDto {

privateLong bookReportId;             //독서 기록 Index번호
privateString userNickname;           // User Nickname
privateString bookName;               //책 제목
privateString title;                  //독서 기록 글 제목
privateLocalDate createAt;            //작성일

publicBookreportResponseDto ( Long bookReportId, String userNickname, String bookName, String title, LocalDate createAt ) {

this.bookReportId = bookReportId;
this.userNickname = userNickname;
this.bookName = bookName;
this.title = title;
this.createAt = createAt;

} //생성자 끝

위의 코드는 Client에게 전달할 Value에 대해 Data를 전송하기 위해 만든 Response DTO 입니다.

DATA 주입에 대한 내용 외에는 DTO에 다른 내용을 넣으면 안된다는 것을 기반으로 하여 Field 변수와 생성자, @Getter 외에는 내용을 추가하지 않았습니다.

 

💨 Repository

---

DataBase에 직접 접근하는 계층으로, DAO 영역에 해당.

 

📌 BookReportRepository.java

public interface BookReportRepository extends JpaRepository < BookReport, Long > {

}

위의 BookReportRepository는 interface이며, JpaRepository를 상속하게 구성하였습니다.

ID Value 기반으로 기본적인 interface들이 선언 되어 있기 때문에 그 외 기능은 위와 같이 규칙에 맞게 구성을 하였습니다.

 

📌 BookReportQueryRepository.java (For querydsl)

@RequiredArgsConstructor
@Repository
public class BookReportQueryRepository {

private finalJPAQueryFactory jpaQueryFactory;
private finalEntityManagerentityManager;

//전체 조회
publicPage<BookreportResponseDto> findAllWithFetchJoin(Pageablepageable) { //페이징 처리

List<BookreportResponseDto> reportList = jpaQueryFactory.select(Projections.fields(
		BookreportResponseDto.class,
		bookReport.bookReportId,
		bookReport.user,
		bookReport.title,
		bookReport.createdAt))
		           .from(bookReport)
		           .innerJoin(bookReport.user,user)
		           .fetch();

		intstart = (int)pageable.getOffset();
		intend = Math.min((start + pageable.getPageSize()), reportList.size() );

return newPageImpl<>(reportList.subList(start, end), pageable, reportList.size());
  } // reportList끝

} // Class끝

 

저희가 Querydsl을 사용한 이유는 Jap를 통해 기본적으로 제공해 주는 @Query로는 다양한 조회 기능을 사용하는데, 한계가 있기 때문에 사용하였습니다.

그래서 위와 같은 문제를 해결하기 위해 Static Type을 지원하는 조회 프레임워크를 사용하기 위해 Querydsl을 선택하여 사용하였습니다.

 

 

---

 

주니하랑의 글이 마음에 드셨나요? 구독과 공감! 그리고, 댓글은 주니하랑에게 많은 힘이 됩니다