MVC Pattern에 대한 다양한 종류의 해석/적용이 있긴 한데... 일단, 내가 생각하기에, 일반적인 SW에서 좋다고 생각하는 구조는 아래와 같다 (Web SW나 기타 여러 case가 존재하고, 각각에 맞는 다양한 해석이 존재할 수 있으니, 정답은 없다.) 물론, 아직 나 자신이 MVC Pattern에 대해 미숙하기 때문에 확신할 수는 없으나...


+-----------+ Query(write/read) +------------+

| | <-------------------------- | |

| Model | | Control |

| | ---------------------------> | |

+-----------+ Response/Data for query +------------+

| | ^

| | |

| Feedback to user(ex. select view) | | User interaction event

| v |

| +------------+

| | |

+--------------------------------------> | View |

Read data / (Observe changes - optional) | |

+------------+


Pros : MVC간 연결이 최소화 되어 있어 각각에 대한 독립성이 잘 보장되어 있다.

Model부분이 최소화 되므로, Data 부분에 대한 안정성을 높이기 유리하다.

Cons : Control부분의 역할이 Model, View에 비해 압도적으로 복잡할 가능성이 높다.

따라서, 복잡한 UX를 가질 경우, Control 부분의 통제가 상당히 어려워질 수 있다.

일단 가장 좋은 점은, Model에 대한 update가 Control로 제한되어 있기 때문에

(View -> Model로 write path가 없다.), Data에 대한 관리가 일원화 되어 있다.

또한, Control이 Model의 data를 update하므로, View는 Model의 Data가 바뀌는지 아닌지 굳이 Observing할 필요가 없다.

(필요에 따라 Observing하는 것도 괜찮다.)



. .


Rough Block Diagram

[Display Device] <>--- [Logical Display] <>--- [WindowManager]

DisplayInfo

has followings (Initial values are set as information from display device).

:logicalHeight

:logicalWidth

:appWidth

:appHeight


DisplayDevice

has followings

:mCurrentLayerStackRect

:mCurrentDisplayRect


shown on the display.

|

v

[LayerStackRect] ---(project to)---> [DisplayRect]

^

|

This value is outbound of WindowManager.


Above information is very rough and... NOT strictly verified.


Here is useful tool supported by Google to handle displaying area and density - wm.

You can find it at '/system/bin/wm'


root@generic:/system/bin # ./wm reset usage: wm [subcommand] [options] wm size [reset|WxH] wm density [reset|DENSITY] wm overscan [reset|LEFT,TOP,RIGHT,BOTTOM]

Very useful isn't it!



+ Recent posts