1. 레이어드 아키텍처
애플리케이션을 여러 계층으로 나우어 각 계층이 특정 역할을 담당하고록 설계하는 방식.
1.1. Presentation Layer (표현 계층)
- 사용자가 애플리케이션과 상호작용하는 계층
- 예: Controller, View
- 역할:
- REST API 요청을 받아 처리하고, 응답을 반환
- 데이터 출력 형식을 결정(HTML, JSON, XML 등)
- 구현: `@Controller`, `@RestController` 등이 포함
1.2. Application Layer (서비스 계층)
- 비즈니스 로직이 구현되는 계층
- 예: Service
- 역할:
- Presentation Layer와 Data Layer 간의 중간다리 역할
- 비즈니스 규칙 처리
- 여러 Repository나 외부 API 호출 등을 조합
- 구현: `@Service` 애너테이션을 통해 구현
1.3. Data Layer (데이터 계층)
- 데이터 저장소와의 상호작용을 담당하는 계층
- 예: Repository
- 역할:
- 데이터베이스와 CRUD(Create, Read, Update, Delete) 작업 처리
- Entity를 이용해 데이터 모델 관리
- 구현: `@Repository`와 JPA(EntityManager), SQL Mapper 등을 사용
1.4. Domain Layer (도메인 계층)
- 도메인 엔티티(Entity) 및 데이터 모델이 정의된 계층
- 역할:
- 데이터 구조를 정의
- 데이터베이스의 테이블과 객체를 매핑
- 구현: `@Entity` 또는 일반 POJO 클래스로 표현
2. MVC 아키텍처
UI관련 애플리케이션에서 주로 사용
2.1. Model
- 데이터와 관련된 모든 것을 담당하며, 데이터 처리와 비즈니스 로직의 핵심이 포함
- 레이어드 아키텍처의 Domain Layer 및 Service Layer와 관련있음
- 구현: `Entity`, `DTO`, `Service` 등이 포함
2.2. View
- 사용자에게 데이터를 표시하는 부분
- HTML, JSP, Thymeleaf, React, Vue.js 등의 프론트엔드 기술이 여기에 포함될 수 있다
- 역할:
- Controller에서 받은 데이터를 시각적으로 표현
2.3. Controller
- 사용자의 요청을 처리하고, 비즈니스 로직 호출 후 View로 결과를 전달
- 레이어드 아키텍처의 Presentation Layer와 동일
- 구현: `@Controller`, `@RestController`를 사용
3. 연관성
- 레이어드 아키텍처는 전체 애플리케이션의 구조를 다루며, 계층별 책임을 분리한다
- MVC 아키텍처는 레이어드 아키텍처의 Presentation Layer를 세부적으로 나눠 View와 Controller의 역할을 명확히 정의한다
- 따라서 레이어드 아키텍처는 애플리케이션의 전체적인 설계 원칙이고, MVC는 그 안에서 UI와 관련된 부분의 설계 원칙으로 작용한다
역할 | 레이어드 아키텍처 | MVC패턴 |
Controller | Presentation Layer | Controller (MVC) |
Service | Business Logic Layer | Model (비즈니스 로직 부분) |
Repository | Data Access Layer | Model (데이터 처리 부분) |
View | 없음 (외부 도구 사용) | View (MVC) |
4. 각 구성요소의 설명
4.1. Entity
- 데이터베이스 테이블과 매핑되는 객체
- JPA(Java Persistence API)를 사용하여 ORM(Object Relational Mapping)을 제공
- 주요 특징
- 클래스 필드 → 데이터베이스 컬럼 매핑
- `@Entity`, `@Table`, `@Id`, `@GeneratedValue` 등으로 구성
- 예
@Entity
@Table(name = "users")
public class User {
@Id
@GeneratedValue(strategy = GenerationType.IDENTITY)
private Long id;
@Column(nullable = false)
private String name;
private String email;
// Getters and Setters
}
4.2. Repository
- 데이터베이스와 상호작용하는 인터페이스
- Spring Data JPA 에서는 기본적으로 CRUD 메서드를 제공한다
- 주요 특징
- `@Repository`로 명시
- 쿼리를 직접 작성하거나 메서드 이름으로 쿼리 자동 생성 가능
- 예
@Repository
public interface UserRepository extends JpaRepository<User, Long> {
Optional<User> findByEmail(String email);
}
4.3. Service
- 비즈니스 로직을 처리하는 클래스
- 데이터 검증, 트랜잭션 관리, 비즈니스 규칙 적용
- `@Service`로 명시
- 예
@Service
public class UserService {
private final UserRepository userRepository;
public UserService(UserRepository userRepository) {
this.userRepository = userRepository;
}
public User createUser(User user) {
// 비즈니스 로직 추가 가능
return userRepository.save(user);
}
public Optional<User> getUserByEmail(String email) {
return userRepository.findByEmail(email);
}
}
4.4. Controller
- HTTP 요청을 받아 Service Layer를 호출하고 결과를 반환
- `@Controller` 또는 `@RestController` 로 명시
- 주요 특징
- URL 매핑 : `@RequestMapping`, `@GetMapping`, `@PostMapping` 등을 통해 HTTP 요청 처리
- JSON, HTML, XML 등의 응답 반환 가능
- 예
@RestController
@RequestMapping("/users")
public class UserController {
private final UserService userService;
public UserController(UserService userService) {
this.userService = userService;
}
@PostMapping
public ResponseEntity<User> createUser(@RequestBody User user) {
User createdUser = userService.createUser(user);
return ResponseEntity.ok(createdUser);
}
@GetMapping("/{email}")
public ResponseEntity<User> getUserByEmail(@PathVariable String email) {
return userService.getUserByEmail(email)
.map(ResponseEntity::ok)
.orElse(ResponseEntity.notFound().build());
}
}
5. 전체 흐름
- 사용자가 브라우저에서 요청을 보냄 (예 : `/users`)
- Controller는 요청을 받고, 필요한 데이터를 Service를 통해 요청
- Service는 비즈니스 로직을 수행하고, Repository에서 데이터를 가져오거나 저장
- Repository는 데이터베이스와 통신하여 결과를 반환
- 결과가 Service → Controller → 클라이언트로 전달
출처 : ChatGPT
'BE > Java' 카테고리의 다른 글
[Java] StringBuffer, StringBuilder (1) | 2024.12.19 |
---|---|
[Java] 영속성 (0) | 2024.12.16 |
[Java] 명령형 , 선언형 프로그래밍 (0) | 2024.12.12 |
[Java] 어노테이션 (1) | 2024.12.11 |
[Java] JDBC와 JPA (0) | 2024.12.11 |