소프트웨어공학 - 15. MVC Architecture pattern

1. Model View Controller Pattern

- 소프트웨어 설계 패턴이다.

- Model : 데이터가 저장되거나, 비지니스 로직이 돌아가는 부분

- View : 화면에 직접 보이는 GUI 파트, 그림을 그리는 것에만 집중

- Controller : 사용자와 UI의 상호작용을 정의하는 부분. 사용자에 요청에 따라 model값을 변경하는 api를 요청한다.

- 이렇게 세 부분으로 프로젝트의 구조를 구분하여 개발하는 것을 말한다.

- 하위 레이어인 Non-UI Layer는 절대 상위 레이어에 의존하지 않는다.

- UI Layer가 하위 Non-UI Layer로 interface를 통해 접근한다.이 의존은 어쩔수 없는 것이지만 그 반대의 경우의 의존 관계가 있어서는 안된다.

- 그래야 자주 UI의 변경이 생기더라도 Model이 있는 layer까지 살펴볼 필요가 없다. 

- view와 controller는 서로 구분이 모호할 수 있지만 model과의 구분은 확실해야 한다.

- 즉 model 안에서 비지니스 로직은 절대 view를 그리거나 하는 동작을 수행해서는 안된다.

- 숫자를 증가시키고 감소시키는 응용 프로그램에 MVC 패턴을 적용했다고 생각해보자.

- veiw는 버튼과 현재 숫자를 보여주는 일만 한다.

- 사용자가 위아래 버튼을 누르면 controller가 사용자의 action을 해석하고 model에게 값을 증가/감소 해달라고 요청한다.

- model은 controller로부터 오는 명령들에 따라 비지니스 로직을 수행하고 데이터를 변경시킨다.

- model은 값이 변경되면 view에게 변경된 값을 다시 그리도록 요청한다.

- 이런 MVC 패턴 덕분에 동일한 모델(코어)에 대해서 다양한 view를 만들 수 있다.

2. Observer pattern

- mvc 패턴중에 하나이다.

- 목적은 같다. model을 view로 부터 분리시키는 것이다.

- publisher 데이터를 갖고 있다. 값에 변화가 생기면 자동으로 subscriber들에게 알려준다.

- 여러 객체들은 publisher를 subscribe, unsubscribe함으로써 데이터의 변화 소식을 들거나 안들을 수 있다.

- 이걸 보면 의미가 더 명확해진다. subject는 변경된 값들을 구독자들에게 알린다. 

- observer들은 내가 관찰하는 값이 변하면 update()한다. 

3. MVC Design Practice

- 실제로 자바에는 Observable interface가 있다. 이 인터페이스를 만족하는 class는 값에 변화가 생길때 notifyObeservers() 함수를 통해 관찰자들에게 알려준다.

- 반대로 관찰자 class의 경우 Observer interface를 만족하면 update(), addObserver()등의 함수를 사용할 수 있다.

- 버튼을 누를때마다 공이 움직이며 벽에 부딪히는 프로그램을 java로 MVC 패턴을 적용하여 만들면 어떻게 될까?

- 모델은 ball의 상태, 윈도우의 크기 정보를 알고 있다. Model은 Observable 객체 여야 view에게 변화를 알려줄 수 있다. 

- setChanged(), notifyObservers()로 신호를 준다.

- 모델은 view나 controller 객체들의 reference를 전혀 가지고 있지 않다.

- view는 ball의 상태를 구독하고 화면에 그리는 작업만 수행한다. view가 뭔가를 판단할 일은 없다.

- 관찰하고 있는 model로부터 신호가 오면 update()한다.

- view는 model, controller의 reference를 가질 수 있다. 이 의존성은 어쩔 수 없다.

- controller는 사용자의 이벤트를 인지하고 model이 값을 변경하도록 요청한다.

- controller는 model, view의 reference를 가질 수 있다. 이 의존성은 어쩔 수 없다.