기본적인 구성은 MVC 아키텍처와 동일하나 몇가지 차이점이 존재한다.
Model
- 앱의 데이터와 비즈니스 로직을 관리.
- 데이터의 상태를 정의하고 이를 변경하는 기능 제공.
View
- 사용자에게 데이터를 시각적으로 표시하는 역할.
- Model의 데이터를 기반으로 UI를 렌더링.
- MVC의 View와 달리 MVP의 View는 데이터를 단순 표시하는 역할만 담당
Presenter
- 사용자 입력(이벤트)을 받아 Model과 View를 조율.
- Model에서 데이터를 가져오거나 수정하고, View에 전달하여 화면을 업데이트.
- MVC의 Controller는 View와 1:n 관계가 가능하나 MVP의 Presenter는 View와 1:1 관계이다.
MVC | MVP | |
사용자 입력 처리 | Controller가 처리 | View가 Presenter에 전달 |
View의 책임 | 데이터 표시와 일부 로직 포함 | 데이터 표시만 담당 (로직 없음) |
중간 계층 | Controller는 여러 View를 처리 가능 (1:n 관계) | Presenter는 각 View와 1:1 관계 |
UI 업데이트 방식 | Model이 View를 직접 갱신하거나 Controller가 View를 업데이트 | Presenter가 View를 항상 직접 업데이트 |
View와 Model 관계 | View는 Controller를 통해 Model과 간접적으로 상호작용하거나 직접 접근 | View는 Presenter를 통해서만 Model과 상호작용 |
유지보수 | Controller는 View와 1:n관계를 가지고 있기에 유지보수가 어려움. | Presenter가 View와 1:1 관계를 갖고 있기에 유지보수 용이. |
테스트 용이성 | Controller는 독립적으로 구성되어 있지 않아 테스트 어려움. (Model과 View간의 상호작용이 가능해서 그럼) | Presenter는 독립적으로 구성되어 있어 테스트 용이. |
class UserModel {
getUser(id) {
// 사용자 데이터를 가져오는 가상 API 호출
return Promise.resolve({ id, name: 'John Doe', email: 'john@example.com' });
}
saveUser(user) {
// 사용자 데이터를 저장하는 가상 API 호출
return Promise.resolve();
}
}
class UserView {
showUserDetails(user) {
document.getElementById('user-name').textContent = user.name;
document.getElementById('user-email').textContent = user.email;
}
showError(message) {
alert(`Error: ${message}`);
}
showSuccess(message) {
alert(`Success: ${message}`);
}
}
class UserPresenter {
constructor(view, model) {
this.view = view; // View 인스턴스
this.model = model; // Model 인스턴스
}
loadUser(id) {
// Model에서 사용자 데이터를 가져옴
this.model.getUser(id)
.then((user) => {
// 데이터를 가공한 후 View에 전달
if (user) {
this.view.showUserDetails(user);
} else {
this.view.showError('User not found');
}
})
.catch((error) => {
// 에러 처리
this.view.showError(error.message);
});
}
saveUser(user) {
// 사용자 데이터를 저장
this.model.saveUser(user)
.then(() => {
this.view.showSuccess('User saved successfully!');
})
.catch((error) => {
this.view.showError(error.message);
});
}
}
동작 순서
- View는 사용자 입력 이벤트를 Presenter에 전달.
- Presenter는 Model과 상호작용하여 데이터를 처리.
- Presenter는 Model에서 데이터를 받아 가공한 뒤, View의 메서드를 호출하여 UI를 갱신.
장점
- View와 Presenter가 1:1 관계이므로, View와 Presenter가 독립적으로 개발되고 테스트 가능.
- Presenter는 해당 View에만 집중하므로, 로직의 복잡성이 분산됨.
단점
- View마다 별도의 Presenter가 필요하므로, View가 많아질수록 Presenter도 많아지고 코드량이 증가.
- 강한 1:1 관계로 인해 View와 Presenter의 변경이 상호 영향을 줄 가능성.
'Dev > 아키텍처' 카테고리의 다른 글
[아키텍처] MVC 아키텍처 (0) | 2025.01.25 |
---|