///MVC (Model - View - Controller)

* 사용하는 패턴들

   = 전략패턴 + 옵저버 패턴 + 컴포지트 패턴

   : 옵저버 패턴

     - 모델로부터 뷰를 분리한다

   : 컴포지트 패턴

     - 뷰 객체들이 컴포지트 패턴으로 구성되어 있다

   : 전략패턴

      - 뷰는 유져 제스쳐에 대한 해석을 컨트롤러에 위임한다

      - 컨트롤러는 다른 해석자를 위해 교체가능하다

 

* Model = 어플리케이션 객체

   - 어플리케이션 상태를 캡슐화한다

   - 상태에 대한 쿼리에 반응한다

   - 어플리케이션 기능을 제공한다

   - 변경된 데이터를 알린다

   - 기업 데이터와 비즈니스 룰

* View = UI

   - 모델의 데이터를 렌더링한다

   - 모델로부터 업데이트를 요청한다

   - 유저 제스쳐를 컨트롤러에게 보낸다

   - 컨트롤러가 뷰를 선택하도록 허락한다

   - 모델의 내용을 그린다

   - 모델을 통해 데이터를 엑세스 한다

* Controller = UI가 User input 에 반응하는 방법을 정의한다

   - 어플리케이션 행동을 정의한다

   - 유저 액션을 모델 업데이트에 맵핑한다

   - 응답을 위해 뷰를 선택한다

   - 각 기능별로 컨트롤러를 만들 수도 있다

   - 뷰와 상호작욜을 모델이 수행할 액션으로 변경한다

 

 

One of the first discussions of MVC, "A Cookbook for Using the Model-View-Controller User Interface Paradigm in Smalltalk-80", by Glenn Krasner and Stephen Pope, was published in the August/September 1988 JournalOfObjectOrientedProgramming. It defined MVC as follows:

"ModelViewController (MVC) programming is the application of this three-way factoring whereby objects of different classes take over the operations related to the application domain (the model), the display of the application's state (the view), and the user interaction with the model and the view (the controller)."

 

Later, the article more closely defines these terms:

"Models -- The model of an application is the domain-specific software simulation or implementation of the application's central structure."

"Views -- In this metaphor, views deal with everything graphical: they request data from their model and display the data."

"Controllers -- Controllers contain the interface between their associated models and views and the input devices (e.g., keyboard, pointing device, time)."

 

In this interpretation, controllers are simple, well-constrained classes that handle processing of the event loop for a particular view.

 

 

However, an interesting reinterpretation of MVC came about in the early 1990s. I believe that a major architect of this reinterpretation was IvarJacobson, who wrote about a similar but not identical architecture in his book, "Object-Oriented Software Engineering: A Use Case Driven Approach" in 1992.

 

Ivar goes on to describe his entity objects as being close to what MVC has described as one type of Model objects - that is to say those objects found in the analysis of the problem domain. This leaves the question of his control objects - what are they? Jacobson himself states: "...in more complex use cases, there often remains behavior that is not naturally placed in either of these two object types [meaning entity and interface objects]. Such behavior is placed in control objects. The control objects typically act as glue which unites other objects so that they form one use case".

 

So, here we see a completely different meaning for "control" or "controller" from what was defined for the "controller" in Smalltalk-80. What happened is that Jacobson's definition (which comes closer to the traditional English meaning of the word "control") has become adopted more and more frequently, to the detriment of the other meaning.

 

    Smalltalk's presentation layer consists of not one, but two, class hierarchies. The outgoing leg of Smalltalk's user interface is handled by a hierarchy of views much like the [View] ones discussed here. But the incoming leg is implemented by a separate hierarchy of classes, Controllers, that provide the logic for parsing cursor and keyboard actions with respect to the view to control the application. My approach differs in that each view is responsible for managing both of these channels. The need for the separate controller hierarchy is unclear and is the topic of spirited debate even within the Smalltalk-80 community [citing "Personal communications with Alan Borning, Trygve Reenskaug, Glen Krasner, and Larry Tesler"].

 

They say that controllers were more useful when Smalltalk was self-hosted. The controller did much of the low-level work of a device driver. When Smalltalk is running on top of an operating system like Windows, the controller becomes almost trivial because the OS does all the work. Further, they note certain problems with the notion of an "application model" object. The thing which represents the application has to know about the views, so should not be part of the Model (which is independent of views). Thus MVP. The Presenter knows about both View and Model, wires them together and routes input events appropriately.

 

* 출처 :

http://wiki.c2.com/?ModelViewController

http://wiki.c2.com/?WhatsaControllerAnyway

http://en.wikipedia.org/wiki/Model-view-controller

 

 

//--------------------------------

https://stackoverflow.com/questions/5863870/how-should-a-model-be-structured-in-mvc

https://pl.csie.ntut.edu.tw/~ctchen/pdf/InsideSmalltalkMVC-public.pdf

https://stackoverflow.com/questions/5966905/what-is-the-right-mvc-diagram-for-a-web-application

https://www.guru99.com/mvc-tutorial.html
https://www.tutorialspoint.com/design_pattern/mvc_pattern.htm

http://fox.wikis.com/wc.dll?Wiki~ModelViewController

http://ootips.org/mvc-pattern.html

http://wiki.c2.com/?ModelViewControllerHistory

 

------------------------------------------------------------------------------------------------------------------------------------

* 2 Tier

 

* 3 Tier

 

* JSP Model 1

> 장점

: 개발이 쉽다

> 단점

: 프로세스의 변경이 생길 경우, 수정이 어렵다

> 실제로 Controller 역할이 없어서 MVC 라고하기 애매함

* JSP Model 2