MVC 패턴 for SARAMARA

카카오 클라우드 스쿨 파이널 프로젝트를 하기 전에, 개발을 해봤던(?) 하려했던(?) 이 프로젝트는 현재 시점에서 손을 떠난지 오래되었기 때문에(약 3달이상) 코드에 대해서 다시 살펴볼 필요가 있었고, 그 당시의 나를 포함한 남정네들 팀원과 현재의 우리는 달라졌기 때문에 이전의 코드를 먼저 리뷰를 하고 스터디와 개발을 병행해서 진행하기로 결정했다.

---

SARAMARA 프로젝트 구조

아래의 구조는 당시 내가 담당했던 부분이다. 진행도가 많이 떨어져있는 것을 알 수 있었고, 차근차근 개발해 나가야 겠다는 의지가 생겼다.

📁 saramara-community-server
|-- 📂 src
	|-- 📂 main
		|-- 📂 java
			|-- 📂 com.kakao.saramaracommunity
				|-- 📂 attach
				|-- 📂 auth
				|-- 📂 board
				|   |-- 📂 dto
				|   |   |-- 📄 BoardDTO.java
				|   |   |-- 📄 BoardPageRequestDTO.java
				|   |   |-- 📄 BoardPageResponseDTO.java
				|   |   
				|   |-- 📂 entity
				|   |   |-- 📄 Board.java
				|   |   |-- 📄 CategoryBoard.java
				|   |   
				|   |-- 📂 repository
				|   |   |-- 📄 BoardRepository.java
				|   |   
				|   |-- 📂 service
				|       |-- 📄 BoardService.java
				|       |-- 📄 BoardServiceImpl.java
				|      
				|-- 📂 comment
				|-- 📂 common
				|-- 📂 config
				|-- 📂 member
				|-- 📄 SaramaraCommunityApplication.java

먼저, 앞서 MVC 패턴에 공부했던 이론에 대해 간략한 설명이다.

✅ Model

• 데이터와 관련된 일을 처리한다.
• Controller와 View에 의존하지 않아서 Controller와 View에 관련된 코드는 없어야 한다.

✅ View

• 사용자에게 보여지는 부분을 담당한다.

✅ Controller

• Model과 View 사이에서 중계자의 역할을 한다.

---

🤔 고민 [1]

Model과 View, 그리고 Controller의 개념은 이론적으로 구분하기는 쉬웠다.

나는 웹 개발을 처음 배울 때, DTO를 사용하는 방식으로 배워서 이 프로젝트에도 단순히 DTO를 사용하는 방법을 통해 개발을 해왔다.

문득, MVC 패턴에 대해서 공부하고 다시 이 프로젝트의 구조를 봤을 때, 아래와 같은 생각이 들었다.

🏋️‍♀️ DTO는 Model에 속하는 것이 맞을까?

그래서 처음부터 다시 공부해보자는 생각으로 DTO에 대해서 찾아보게 되었고, 아래와 같은 이유로 DTO가 Model과 연관있다는 것 으로 판단을 했다.

DTO는 MVC패턴의 Model안에 있는 개념이 아니라 별개의 Layer로 봐야하는 것이 맞는 것 같고, MVC패턴 이라는 Model, View, Controller 부분에 굳이 DTO를 넣는다면 DTO는 Model에 가깝다라고 표현하는 것이 더 맞는 표현이지 않을까 하는 생각이다.

🏋️‍♀️ DTO란?

Data Transfer Object로 계층(Controller, View) 간 데이터를 교환하기 위한 Java beans라는 것을 어느 한 블로그를 통해 보게 되었다.
Controller는 View - Model의 데이터를 주고 받을 때 별도의 DTO를 주로 사용한다고 한다.

🏋️‍♀️ 그렇다면 DTO를 사용하는 이유는 무엇일까?

DTO를 간단하게 이해하자면, 각 클레스를 이동할 때마다 DTO라는 이동 수단을 통해 데이터를 옮기는 것 같다.

위의 그림을 보면 데이터를 움직일 때 Entity 객체를 그대로 사용해도 될 듯해 보이는데 왜 DTO를 만들어서 사용하는 지 의문이 생길 수 있다.

DTO를 사용하는 이유는 아래와 같다.

• View Layer와 DB Layer의 역할을 분리하기 위해서:
  객체를 표현하기 위한 계층과 저장하는 계층의 분리를 위해 DTO를 사용한다.
• Entity 객체의 변경을 피하기 위해서:
  Entity 객체를 그대로 사용하면 프로그래머의 의도와는 다르게 데이터가 변질될 수 있다.
• View와 통신하는 DTO는 자주 변경된다:
  View와 통신하는 DTO 클래스, 예로, ResponseDTO, RequsetDTO는 요구사항에 따라 자주 변경이된다. 어떤 요청에는 특정 값이 추가될 수 있고, 없을 수도 있다. 따라서 Entity 클래스와 분리해서 사용해야한다.

---

👨🏻‍💻 Board

지난 코드를 확인해보니 MVC 패턴 적용 대해 어색한 부분은 찾아볼 수 없었다. 하지만, 진행이 얼마되지 않은 상태이므로, 이 후 개발 진행에 있어 MVC 패턴을 잘 지켜지고 있는지를 확인하면서 진행이 필요하다 생각이된다.

✅ Controller, View

Controller와 View는 코드 작성이 되어있지 않아서 코드 리뷰는 생략한다.

✅ Model

📄 dto.BoardDTO

우선, DTO를 사용하기 위해 모든 객체들을 사용했다. DTO를 사용하는 것 자체에는 문제가 없다고 생각되었지만, 명확하게 어떤 부분에서 사용될 DTO인지 세분화할 필요가 있어보인다. 이 부분은 개발을 진행하면서 필요한 부분에 맞게 DTO를 나눠서 클래스를 생성할 계획을 세워야 할 필요를 느꼈다.

📄 dto.BoardPageRequestDTO

📄 dto.BoardPageResponseDTO

BoardPageRequestDTO, BoardPageResponseDTO는 삭제가 필요하다 생각이 들었다.
페이징 처리를 위해 생성한 DTO 클래스 였는데, 개발의 순서상 지금 개발될 부분이 아니라고 판단이 된다. 이 프로젝트의 페이징 처리는 무한스크롤을 하기로 하였고, 그 방법에 대해서는 여러가지 방법이 있을 것으로 생각이 되므로, 그 방법이 결정되고 나면 그에 맞게 작성될 필요가 있다고 생각하기 때문에 현재는 삭제를 해야겠다고 판단했다.

📄 entity.Board

MVC 패턴에 대한 문제를 찾지 못했다. 다만, 작성된 PrePersist나 Lob과 같은 어노테이션을 사용했던 이유가 있었는데 왜 사용했는지를 기억하지 못했다.
따라서, 해당 어노테이션에 대해 조금 더 알아보려 한다.

@Lob: Large Object의 줄임말인 어노테이션으로, 필드에 특정 문자열 길이를 지정하지 않는다면 Default로 varchar(255)까지 저장할 수 있지만, 사진을 저장하는 컬럼으로 사용할 경우에는 더 많은 자리수를 사용하기 때문에 @Lob 어노테이션으로 데이터베이스에 적절히 저장한다.

당시, 내용에 대한 글이 많아질 수도 있지 않을까? 사용자에 따라 글을 많이 쓸 수도 있잖아? 하고 사용한 것을 기억했다.

@PrePersist: JPA 엔티티 라이프 싸이클의 콜백을 조종할 수 있게 하는 어노테이션으로 아래와 같은 어노테이션이 존재하고 이런 콜백 이벤트들을 사용하는 방법은 엔티티 내부에 직접 메서드를 작성해주는 것과 EntityListener를 만들어주는 방법이 있다.

EntityListener를 사용할 때 유의할 점은 콜백 메서드들은 void 타입을 리턴해야 한다는 점이다.
entity를 만들고 repository의 save 메서드를 호출할 때 @PrePersist가 달린 메서드가 호출이 되고 DB에 insert 된 후에 @PostPersist 메서드가 호출이 된다.
만약, @GeneratedValue로 PK를 자동 생성하면 해당 PK는 @PostPersist를 사용할 수 있을 것이다.

다시 간단하게 알아보았지만, 명확하게 어노테이션을 이해하지 못했다. 따라서, 해당 부분은 이해를 명확하게 한 뒤에 적용을 해야겠다고 생각한다.(스터디를 해봐도 좋을 듯 하다.)

📄 entity.CategoryBoard

enum 클래스로서 문제될 것이 없다고 판단한다.

📄 repository.BoardRepository

Page에 대한 부분은 TODO 주석과 같이 페이지에 대한 처리를 고민한 뒤에 적용해야하므로 제거가 필요하다 생각한다.

📄 service.BoardService

📄 service.BoardServiceImpl

현재 진행된 부분까지는 문제가 없다고 본다.

---

🤔 고민 [2]

🏋️‍♀️ Service 클래스를 인터페이스와 Impl 클래스로 나눠서 개발할 필요가 있을까?

Spring에서 Service 인터페이스를 나눠서 사용하는 이유는 아래와 같았다.

• 인터페이스와 구현체를 분리함으로써 구현체를 독립적으로 확장할 수 있다.
• 구현체 클래스를 변경하거나 확장해도 이를 사용하는 클라이언트의 코드에 영향을 주지 않도록 하기 위함.

이 같은 추상화를 통한 구현 방식은 객체지향의 특징 중 하나인 다형성과 객체지향의 다섯가지 원칙 중 하나인 OCP 원칙을 가장 잘 실현해주는 설계 방식이라고 할 수 있다.

하지만, 인터페이스와 구현체 클래스 사이의 관계가 1:1 관계로 구성되어 실질적으로 인터페이스와 클래스 구조를 사용하는 것에 대한 이점을 전혀 가져가지 못함에도 불구하고 관습적으로 이러한 추상패턴을 적용하고 있다.

• OCP (Open Closed Principle)
  개방, 폐쇄 원칙이라고 하며 '소프트웨어 개체(클래스, 모듈, 함수 등)는 확장에 대해 열려 있어야 하고, 수정에 대해서는 닫혀 있어야 한다.'는 프로그래밍 원칙이다.

• 위 추상화를 통한 구현 방식의 단점
  코드 구조가 복잡해지고, 복잡해진 구조 만큼 코드를 분석하고 확인하는 과정에서 인터페이스를 거쳐 구현체들을 확인해야 하는 번거로움이 생길 수 있다.

따라서, 이렇게 개발 중인 프로젝트 내에 Service를 나눠서 왜 구분하는지를 잘 알지 않는 이상, 관습적으로 분리해서 번거로워질 이유가 없다고 판단된다.

🚀 마무리하며

다른 팀원이 담당한 코드들도 살펴볼 예정인데, 해당 부분들을 봤을 때, 특별하게 MVC 패턴에 맞지않는 부분은 찾지 못했다. 하지만, 동일한 고민거리들이 몇몇이 보였고, 미팅을 통해 서로 커뮤니케이션을 해서 어떠한 방향으로 나아갈지 고민해볼 필요를 느꼈다.
그리고, 내가 담당했던 부분은 이 어노테이션을 어떠한 이유로 왜 사용했는지에 대해서 꼼꼼히 살펴볼 필요를 느꼈고, 현재의 내가 기억을 잘 못하고 있던 것 처럼 주석을 통해 어떤 내용인지를 상세히 적어둬야겠다는 생각이 들었다.

---

Reference

👨🏻‍💻 witwint님의 블로그: Spring DTO의 사용 이유
👨🏻‍💻 geesuee님의 블로그: MVC와 DTO
👨🏻‍💻 bepoz님의 블로그: [JPA] @PrePersist 어노테이션에 대해
👨🏻‍💻 Youngho님의 블로그: Spring에서 Service ServiceImpl 사용해야하는지