MVC 모델과 UML 클래스 표현법
작성자: Ospace (ospace114 at naver.com) http://discount77.com/blog/ospace
MVC란 Model, View, Controller을 줄여서 표현한 것이다.
기능별로 구분하여 유지보수를 쉽게하기 위한 목적이다.
그리고 각각은 UML에서 Model은 Entity로 View는 Boundary로 Controller는 Control으로 대응할 수 있다.
아래 그림은 일반적인 MVC 모델을 참조하였다. 사실 어느 모델에 기반을 했는지 기록하지 않아서 정확히는 모르겠다. 찾아보면 나오는데 귀차니즘으로 인해서.. ㅡ.ㅡㅋ
위의 MVC 모델은 Control과 View가 같이 묶여 있다. MFC 해본 개발자라면 MFC의 Document-View 구조와 비슷하다고 느끼실거다.
아래 하늘색으로 된 표형태 그림은 클래스 UML 표기법에서 클래스 표현 방법을 간략하게 정리하였다. 단순 참고용으로 그렸기에 더 추가적인 내용은 다른 곳에서 참고하세요.^^ㅋ
그리고 원형태의 그림이 3개가 보인다. 이는 Control, View, Entity를 가리키며, MVC 모델과 대응되게 위치시켰다.
MVC 모델은 다양한 형태로 구성될 수 있으며, 여러가지 방법으로 구현이 가능하기에 위의 그림이 정확한 형태라고 보기는 힘들다. 위의 그림도 그 중에 한가지로서 단순 참고용으로 활용하기 바란다. 그저 생각의 폭을 넓혀주기 위한 낙서정도~ㅋㅋㅋ
그리고 MVC 각각에 메시지와 액세스 통신 방법이 약간 다를 수 있다. 예를 드어 현재 Controller에서 VIew로 메시지를 보내는 것으로 끝나지만 View에서 Controller로 사용자 명령 처리하는 메시지가 보내질 수 있다. 여기서는 바로 Controller로 사용자 입력(User Input)을 받는 형태로 보여주고 있다.
그리고 Model에서 메시지 보내는 대상이 View로 되어 있는 경우도 많으나 여기서는 Controller로도 보내고 있다. 다음 두가지 경우로 구분할 수 있다.
(1) Model에서 View로만 값이 변경되었다는 메시지를 보냄
(2) Model에서 View와 Controller로 값이 변경되었다는 메시지를 보냄
일반적으로 (1)인 경우가 흔하고 그렇게 보는게 합당하다. 이럴 경우는 Model에 값을 변경하는 역활은 Controller이 하고 View에서 값을 사용하여 화면에 표시하는 역활을 가진다. View가 Model에 값을 변경하지 않은다는 조건에서 합당하다.
(2)의 경우는 View도 Model의 값을 변경할 수 있다는 전제조건하에서 이뤄진다. 즉 View에 의해 변경된 값이 Controller에 의해 처리할 필요성이 있기 때문이다.
참고로 MFC는 View와 Control이 밀접하게 연결이 되어 있어서 따로 분리하기 힘들다. 할 수 없이 일단 View에서 사용자 입력을 받고, 바로 Control으로 넘겨주는 방식이 가능하나, 이는 완벽한 View와 Control 분리라 볼 수 없다. View 변경시 View 코드에서 변경되야할 부분이 많이 발생한다. 그래도 Control 코드를 분리하는게 나중에 View 교체시 변경할 코드가 줄어드는건 사실이다.
덧글:
위의 Acess와 Message라는 두가지 호출 방식이 있다. 시실 Acess는 쉽게 감이 오지만 Message는 바로 오지 않은다. 이는 개발자들이 직접 호출 방식에 익숙해져 있기 때문이고, 실제 구현에서도 직접 호출 형태를 주로 사용한다.
직접 호출이라고 하면 특정 클래스의 메소드 혹은 함수를 직접 함수명으로 호출을 하는 형태이다. 즉, 동기처리라고 보면 된다. 바로 처리하는 형태이다.
Message는 간접 처리형태로 보면되고, Message 발생 즉시에 실행하는 것이 아니라, 자신 순번에 오면 그때가서 실행하는 형태이다. 그렇기에 비동기 형식이라 말할 수 있다.
비동기 형식이라서 실행이 되지 않을까하는 불안감으로 인해 신뢰도이 떨어지기에 사용하기 꺼려지기 때문이다. 사실 실행되지 않는게 아니고 나중에 실행할 뿐이다. 그렇기에 그 동안 다른 작업을 할 수 있으며, 작업에 효율성을 가져온다. 단, 디버깅이 힘들다는 문제점은 있다.
작성자: Ospace (ospace114 at naver.com) http://discount77.com/blog/ospace
MVC란 Model, View, Controller을 줄여서 표현한 것이다.
기능별로 구분하여 유지보수를 쉽게하기 위한 목적이다.
그리고 각각은 UML에서 Model은 Entity로 View는 Boundary로 Controller는 Control으로 대응할 수 있다.
아래 그림은 일반적인 MVC 모델을 참조하였다. 사실 어느 모델에 기반을 했는지 기록하지 않아서 정확히는 모르겠다. 찾아보면 나오는데 귀차니즘으로 인해서.. ㅡ.ㅡㅋ
위의 MVC 모델은 Control과 View가 같이 묶여 있다. MFC 해본 개발자라면 MFC의 Document-View 구조와 비슷하다고 느끼실거다.
아래 하늘색으로 된 표형태 그림은 클래스 UML 표기법에서 클래스 표현 방법을 간략하게 정리하였다. 단순 참고용으로 그렸기에 더 추가적인 내용은 다른 곳에서 참고하세요.^^ㅋ
그리고 원형태의 그림이 3개가 보인다. 이는 Control, View, Entity를 가리키며, MVC 모델과 대응되게 위치시켰다.
MVC 모델은 다양한 형태로 구성될 수 있으며, 여러가지 방법으로 구현이 가능하기에 위의 그림이 정확한 형태라고 보기는 힘들다. 위의 그림도 그 중에 한가지로서 단순 참고용으로 활용하기 바란다. 그저 생각의 폭을 넓혀주기 위한 낙서정도~ㅋㅋㅋ
그리고 MVC 각각에 메시지와 액세스 통신 방법이 약간 다를 수 있다. 예를 드어 현재 Controller에서 VIew로 메시지를 보내는 것으로 끝나지만 View에서 Controller로 사용자 명령 처리하는 메시지가 보내질 수 있다. 여기서는 바로 Controller로 사용자 입력(User Input)을 받는 형태로 보여주고 있다.
그리고 Model에서 메시지 보내는 대상이 View로 되어 있는 경우도 많으나 여기서는 Controller로도 보내고 있다. 다음 두가지 경우로 구분할 수 있다.
(1) Model에서 View로만 값이 변경되었다는 메시지를 보냄
(2) Model에서 View와 Controller로 값이 변경되었다는 메시지를 보냄
일반적으로 (1)인 경우가 흔하고 그렇게 보는게 합당하다. 이럴 경우는 Model에 값을 변경하는 역활은 Controller이 하고 View에서 값을 사용하여 화면에 표시하는 역활을 가진다. View가 Model에 값을 변경하지 않은다는 조건에서 합당하다.
(2)의 경우는 View도 Model의 값을 변경할 수 있다는 전제조건하에서 이뤄진다. 즉 View에 의해 변경된 값이 Controller에 의해 처리할 필요성이 있기 때문이다.
참고로 MFC는 View와 Control이 밀접하게 연결이 되어 있어서 따로 분리하기 힘들다. 할 수 없이 일단 View에서 사용자 입력을 받고, 바로 Control으로 넘겨주는 방식이 가능하나, 이는 완벽한 View와 Control 분리라 볼 수 없다. View 변경시 View 코드에서 변경되야할 부분이 많이 발생한다. 그래도 Control 코드를 분리하는게 나중에 View 교체시 변경할 코드가 줄어드는건 사실이다.
덧글:
위의 Acess와 Message라는 두가지 호출 방식이 있다. 시실 Acess는 쉽게 감이 오지만 Message는 바로 오지 않은다. 이는 개발자들이 직접 호출 방식에 익숙해져 있기 때문이고, 실제 구현에서도 직접 호출 형태를 주로 사용한다.
직접 호출이라고 하면 특정 클래스의 메소드 혹은 함수를 직접 함수명으로 호출을 하는 형태이다. 즉, 동기처리라고 보면 된다. 바로 처리하는 형태이다.
Message는 간접 처리형태로 보면되고, Message 발생 즉시에 실행하는 것이 아니라, 자신 순번에 오면 그때가서 실행하는 형태이다. 그렇기에 비동기 형식이라 말할 수 있다.
비동기 형식이라서 실행이 되지 않을까하는 불안감으로 인해 신뢰도이 떨어지기에 사용하기 꺼려지기 때문이다. 사실 실행되지 않는게 아니고 나중에 실행할 뿐이다. 그렇기에 그 동안 다른 작업을 할 수 있으며, 작업에 효율성을 가져온다. 단, 디버깅이 힘들다는 문제점은 있다.
반응형
'1.관리 및 아키텍처 > Architecture' 카테고리의 다른 글
| 윈도우 메모리 구조 (0) | 2009.10.07 |
|---|---|
| 16F84A 메모리 구조 (0) | 2009.09.25 |
| 통신 프로토콜 스팩 (0) | 2009.03.04 |
| 코딩 스타일 (0) | 2008.12.09 |
| 동영상 화질 이야기 (0) | 2007.05.10 |
