"컨트롤러"의 두 판 사이의 차이

 
(같은 사용자의 중간 판 2개는 보이지 않습니다)
3번째 줄: 3번째 줄:
;컨트롤러, 컨트롤러 패턴
;컨트롤러, 컨트롤러 패턴
* [[GRASP]]의 하나
* [[GRASP]]의 하나
* 컨트롤러 패턴은 전체 시스템 또는 유스케이스 시나리오를 나타내는 non-UI 클래스에 시스템 이벤트를 처리하는 책임을 할당한다.
* 컨트롤러는 시스템 이벤트를 수신하거나 처리하는 non-UI 객체이다.
* 컨트롤러 객체는 시스템 이벤트를 수신하거나 처리하는 non-UI 객체이다.
* 전체 시스템 또는 유스케이스 시나리오를 나타내는 non-UI 클래스에 시스템 이벤트를 처리하는 책임을 할당한다.
* 문제: 누가 입력 시스템 이벤트를 처리해야 하는가?
* 문제점: 누가 입력 시스템 이벤트를 처리해야 하는가? 사용자의 요청(주로 UI 계층)을 실제 로직 처리 객체에 어떻게 전달할까?
:사용자의 요청(주로 UI 계층)을 실제 로직 처리 객체에 어떻게 전달할까?
* 해결책: 유스케이스 컨트롤러는 유스케이스의 모든 시스템 이벤트를 처리하는 데 사용해야 하며 둘 이상의 유스케이스에 사용될 수 있다.
* 해결책: 유스케이스 컨트롤러는 유스케이스의 모든 시스템 이벤트를 처리하는 데 사용해야 하며 둘 이상의 유스케이스에 사용될 수 있다.
:예를 들어 Create User 및 Delete User 유스케이스의 경우, 개별 유스케이스 컨트롤러 대신 UserController라는 단일 클래스를 가질 수 있다.
:예를 들어 Create User 및 Delete User 유스케이스의 경우, 개별 컨트롤러 클래스(CreateUserController, DeleteUserController) 대신 단일 클래스(UserController)를 만들자.
* 관련 패턴 또는 원칙 : [[커맨드 패턴]], [[파사드 패턴]], [[레이어 (객체지향)|레이어]], [[순수 가공]]
* 관련 패턴 또는 원칙 : [[커맨드 패턴]], [[파사드 패턴]], [[레이어 (객체지향)|레이어]], [[순수 가공]]
* 장점: 컨트롤러 재사용, 유스케이스에 따른 유지보수 용이
* 장점: 컨트롤러 재사용, 유스케이스에 따른 유지보수 용이
15번째 줄: 14번째 줄:
:하나의 컨트롤러에 너무 많은 책임이 부여되었다면 분할하자.
:하나의 컨트롤러에 너무 많은 책임이 부여되었다면 분할하자.
:하나 이상의 컨트롤러를 지원하는 별도 클래스를 만드는 것도 좋다.
:하나 이상의 컨트롤러를 지원하는 별도 클래스를 만드는 것도 좋다.


==같이 보기==
==같이 보기==

2022년 6월 16일 (목) 11:22 기준 최신판

1 개요[ | ]

controller, controller pattern
컨트롤러, 컨트롤러 패턴
  • GRASP의 하나
  • 컨트롤러는 시스템 이벤트를 수신하거나 처리하는 non-UI 객체이다.
  • 전체 시스템 또는 유스케이스 시나리오를 나타내는 non-UI 클래스에 시스템 이벤트를 처리하는 책임을 할당한다.
  • 문제점: 누가 입력 시스템 이벤트를 처리해야 하는가? 사용자의 요청(주로 UI 계층)을 실제 로직 처리 객체에 어떻게 전달할까?
  • 해결책: 유스케이스 컨트롤러는 유스케이스의 모든 시스템 이벤트를 처리하는 데 사용해야 하며 둘 이상의 유스케이스에 사용될 수 있다.
예를 들어 Create User 및 Delete User 유스케이스의 경우, 개별 컨트롤러 클래스(CreateUserController, DeleteUserController) 대신 단일 클래스(UserController)를 만들자.
하나의 컨트롤러에 너무 많은 책임이 부여되었다면 분할하자.
하나 이상의 컨트롤러를 지원하는 별도 클래스를 만드는 것도 좋다.

2 같이 보기[ | ]

3 참고[ | ]