Spring MVC 아키텍처 계층 구조 + Entity와 DTO를 변환하는 이유

1. 구조 단계별 설명

Client

• 사용자 또는 클라이언트가 요청을 보냅니다.
• 웹 페이지나 모바일 애플리케이션이 클라이언트 역할을 합니다.

Controller

• 역할: 클라이언트의 요청을 받고 적절한 서비스를 호출합니다.
• DTO 사용: 클라이언트가 보낸 데이터를 DTO (Data Transfer Object)로 받아 처리합니다.
• 주요 기능:
  • 요청(Request) 데이터 검증
  • Service 계층에 데이터 전달
  • 처리 결과를 클라이언트에게 반환

Service

• 역할: 비즈니스 로직을 담당합니다.
• Controller에서 넘어온 DTO를 처리하고 Entity로 변환해 Repository로 전달합니다.
• ServiceImpl: 비즈니스 로직의 세부 구현을 처리하는 클래스입니다.

DAO (Repository)

• DAO (Data Access Object): 데이터베이스와의 직접적인 상호작용을 담당합니다.
• Spring Data JPA에서는 Repository를 통해 데이터 접근이 이루어집니다.
• DAOImpl: DAO 인터페이스의 구현체로, 복잡한 쿼리나 로직을 처리합니다.

DB (Database)

• 애플리케이션의 데이터를 저장하고 관리하는 실제 데이터베이스입니다.

---

이 구조를 사용하는 이유

1. 관심사 분리 (Separation of Concerns)
   • 각 계층이 명확하게 구분되어 역할이 분리됩니다.
     • Controller: 요청 처리
     • Service: 비즈니스 로직
     • DAO: 데이터 접근
   • 덕분에 코드의 유지보수와 확장성이 용이해집니다.
2. 유연한 구조
   • 레이어 간의 결합도가 낮아 다른 레이어를 수정하더라도 나머지 부분에 미치는 영향이 최소화됩니다.
   • 예: DAO를 다른 데이터베이스로 교체해도 Service 계층에 영향을 주지 않음.
3. 재사용성
   • Service와 DAO 계층은 여러 Controller에서 재사용할 수 있습니다.
   • 비즈니스 로직을 한 곳에 모아 관리하기 때문에 코드 중복이 줄어듭니다.
4. 테스트 용이성
   • 각 계층을 독립적으로 단위 테스트할 수 있습니다.
   • 예: Service 계층만 테스트하거나 DAO 계층만 Mock 데이터를 통해 테스트 가능.

---

Entity와 DTO를 구분하는 이유

1. Entity란?

• 데이터베이스의 테이블과 매핑되는 객체입니다.
• JPA에서 사용되며, 주로 데이터베이스와 직접적으로 연관된 정보를 포함합니다.

2. DTO란?

• Data Transfer Object의 약자로, 계층 간 데이터를 전송할 때 사용하는 객체입니다.
• 주로 클라이언트와 서버 간 데이터 교환에 사용됩니다.

Entity와 DTO를 구분하는 이유

1. 보안 강화
   • Entity는 데이터베이스 테이블 구조와 직결되므로 클라이언트에 노출되면 보안에 위험이 있을 수 있습니다.
   • DTO는 필요한 데이터만 전송하므로 불필요한 정보 노출을 방지합니다.
2. 유연성 증가
   • 클라이언트 요구사항에 따라 DTO 구조를 유연하게 변경할 수 있습니다.
   • Entity는 데이터베이스 테이블과 1:1 매핑이므로 구조 변경 시 부담이 큽니다.
3. 관심사 분리
   • Entity는 데이터베이스와의 연동에 집중하고, DTO는 데이터 전송에만 집중하도록 역할을 분리합니다.
4. 유지보수 용이
   • Entity와 DTO를 분리하면 데이터베이스 스키마와 상관없이 API의 데이터 형태를 변경하거나 확장하기가 쉽습니다.

---

FAQ

왜 레이어를 이렇게 나누어야 하나요?

• 유지보수성과 재사용성을 높이기 위해 레이어를 나눕니다.
• 비즈니스 로직(Service)과 데이터 접근(Repository)을 분리하면 코드가 독립적으로 동작하며 테스트하기도 쉽습니다.

DTO와 Entity를 하나로 합치면 안 되나요?

• 합칠 수는 있지만, 보안 문제와 유연성이 저하됩니다.
• 예를 들어, Entity에 불필요한 컬럼이나 민감한 정보가 포함될 수 있고, 클라이언트 요구에 따라 필드를 변경하기도 어렵습니다.

ServiceImpl과 DAOImpl 같은 구현체는 왜 따로 만들죠?

• 인터페이스와 구현을 분리하면 유연성과 확장성이 증가합니다.
• 예를 들어, 다른 데이터베이스나 외부 API로 변경될 때 구현체만 수정하면 됩니다.

Spring Data JPA를 쓰면 DAOImpl이 필요 없나요?

• Spring Data JPA는 기본적인 CRUD 기능을 제공하기 때문에 DAOImpl 없이 Repository 인터페이스만으로 충분합니다.
• 하지만 복잡한 쿼리가 필요하면 커스텀 구현체를 추가할 수 있습니다.

---