비록 시작은 코딩일기지만, 그 끝은 창대하게
어엿한 개발자 블로그로 성장할 수 있도록.

---

Spring Study

본 게시글은
Endless Creation Spring Study
에 사용하는 자료입니다.

---

Structure of Web Application

간단한 Web Application 구성 요소

간단한 Web Application 을 개발할 때 사용하는 전형적인 구조는 다음의 요소를 갖는다.

• Front Servlet
• Controller + View
• Service
• DAO

각각에 대해 하나씩 살펴보자.

Front Sevlet

Front Servlet 은 클라이언트(브라우저)의 모든 요청을 받고 알맞은 Controller에 전달한다. Spring MVC 에서는 DispatcherServlet 이 이 역할을 담당한다.

Controller + View

Controller 는 실제 클라이언트의 요청을 처리한다. Controller는 클라이언트(브라우저)의 요청을 처리하기 위해 알맞은 기능을 실행하고 그 결과를 뷰에 전달한다(MPA, SSR).

Controller의 주요 역할은 다음과 같다.

• 클라이언트가 요구한 기능을 실행
• 응답 결과를 생성하는데 필요한 모델 생성
• 응답 결과를 생성할 View 선택

Controller는 Application이 제공하는 기능과 사용자 요청을 연결하는 매개체로서 기능제공을 위한 핵심 비즈니스 로직을 직접 수행하지는 않는다. 대신 해당 로직을 제공하는 Service에 그 처리를 위임한다.

Service

Service 는 기능의 핵심 비즈니스 로직을 구현한다. 비밀번호 변경 기능을 예로 들면, 핵심 로직은 비밀번호를 변경하는 것 이다. form을 보여주는 로직이나 로그인 여부를 체크하는 로직은 핵심이 아니다.

Service 는 DataBase연동이 필요하면 DAO를 사용한다. DAO는 Data Access Object 의 약자로 DataBase와 Appication 간에 Data를 이동시켜 주는 역할을 맡는다. Application은 이 DAO를 통해 DataBase에 데이터를 추가하거나 데이터를 읽어온다.

부가적인 로직이 없는 간단한 기능, 로직의 경우 Controller에서 직접 DAO를 사용하기도 한다.

---

Service의 구현

Service는 핵심이 되는 비즈니스 로직을 수행한다. 비밀번호 변경 기능을 예로 들면 다음의 로직을 수행한다.

• DataBase에서 비밀번호를 변경할 회원의 데이터를 구한다.
• 존재하지 않으면 Exception을 발생시킨다.
• 회원 데이터의 비밀번호를 변경한다.
• 변경 내역을 DataBase에 반영한다.

Application을 사용하든 콘솔창에서 실행하든 비밀번호 변경 기능을 제공하는 Service는 동일한 로직을 수행한다. 이런 로직들은 한 번의 과정으로 끝나기보다는 위 예처럼 몇 단계의 과정을 거치게 된다. 중간 과정에서 실패가 나면 이전까지 했던것을 취소해야 하고, 모든 과정을 성공적으로 진행했을 때 완료해야 한다. 이런 이유로 Service의 메소드를 한 트랜잭션 범위 내에서 실행한다(@Transactional).

Service Class의 구현 방식에는 기능별로 Class를 작성하거나, 같은 데이터를 사용하는 기능들을 한 개의 Class에 모아서 구현할 수 있다.

기능별로 Class를 작성 예

• MemberRegisterService : 회원 가입 기능 제공
• ChangePasswordService : 비밀번호 변경 기능 제공

한 개의 Class에 모아서 작성 예

• MemberService : 회원 관련 기능 제공

추가로, 어떠한 로직도 수행하지 않고 단순히 DAO의 메서드만 호출하고 끝나는 정도라면 Controller에서 직접 DAO에 접근해도 괜찮다.

---

패키지 구성

앞서 간단히 얘기했지만 패키지 구성에는 크게 두 가지 정도로 정리할 수 있다.

1. 기능별로 묶기

• project
  • src/main/java
    • AAA
      • AAAController
      • AAAService
      • AAA
      • AAARepository
    • BBB
      • BBBController
      • BBBService
      • BBB
      • BBBRepository
    • DDD
      • DDDController
      • DDDService
      • DDD
      • DDDRepository
  • src/main/resources
    • ...
  • src/test/java
    • ...

2. 역할별로 묶기

• project
• src/main/java
  • controller
    • AAAController
    • BBBController
    • DDDController
  • service
    • AAAService
    • BBBService
    • DDDService
  • domain
    • AAA
    • BBB
    • DDD
  • repository
    • AAARepository
    • BBBRepository
    • DDDRepository
• src/main/resources
  • ...
• src/test/java
  • ...

두 가지로 나누어 보았지만, 사실 패키지 구성에는 정답이 없다. 중요한 것은 팀원들끼리 충분한 협약을 거친 후에 그 협약에 맞게 일관되게 패키지를 구성해야 한다는 것이다.

---

Repository, DAO, DTO, VO

각각에 대해 특징만 간단하게 정리해보자.

Repository

• Domain-Driven Design(DDD) 의 기본 빌딩 블록 중 하나
• JPA와 같은 ORM을 사용하게 되면 객체 단위로 테이블을 관리 (Entity)
• 이 때 Repository는 DAO의 역할을 대신한다.

DAO

• (Like Repository)
• Data Access Object
• 실제로 DB에 접근하는 객체
• DB접근 로직과 비즈니스 로직을 구분하기 위함

DTO

• Data Transfer Object
• Layer간의 통신 및 데이터 교환 용도로 오고가는 객체
• 로직을 갖고 있지 않는 순수한 데이터 객체 (getter/setter 메서드만 보유)
• Entity 로 DTO를 대체할 수 없으며 이는 꼭 주의해야함!

VO

• Value Object
• DTO와 동일한 역할
• 특정한 비즈니스 값을 담는 객체
• 차이점 : read only

---

Repository vs VO

아주 좋은 글 이 있으니 천천히 읽어보면 좋을 것 같다.