MVC 패턴

MVC 패턴이 무엇일까 ❓

• MVC 패턴은 디자인 패턴중 하나로써, Model / View / Controller로 구성되어 있는 패턴이다.
  • 그럼 디자인 패턴은 뭔가요❓
    • 디자인 패턴은 소프트웨어 설계 시 자주 발생하는 고질적인 문제들을 해결하기 위한 해결책을 만들어서 재사용하여 문제점을 처리하는 것을 의미한다. 디자인 패턴은 개발자 간 의사소통 또한 원할하게 해주는 아주 중요한 역할을 해준다고 할 수 있다.
      • 디자인 패턴은 크게 생성(Creational)패턴, 구조(Structural)패턴, 행위(Behavioral)패턴이 있다.

출처 : 위키백과

 

Model & View & Controller

1. Model

✏️ Model은 컨트롤러가 호출하면 DB와 연동하여 데이터의 입출력과 데이터와 연관된 비지니스 로직을 처리하는 역할이다. 

쉽게 말해서 데이터와 관련된 것이라고 생각하자!

 

2. View

✏️ View는 사용자에게 보여주는 화면(UI)이다. 웹의 경우 html과 css로 나타내는 요소들이다.

 

3. Controller

✏️ Controller는 Model과 View 사이를 이어주는 인터페이스 역할!

즉 데이터를 어떻게 처리할지 알려주는 역할인 셈이다.

 

📌 Model & View는 서로의 존재를 몰라야만 한다!

MVC 왜 씀❓

• 결론을 먼저 말하자면 유지보수의 편리성을 위해서 사용한다. 아무리 잘 설계된 시스템이라도 유지보수를 시작하면 각 기능간의 결합도가 높아지는 경우가 발생하는데, 이는 사소한 코드의 변경이 다른 비즈니스 로직에 영향을 끼칠 수 도 있기 때문에 결합도가 높은 소프트웨어는 위험하다라고 말할 수 있다.
• 따라서 뷰, 모델, 컨트롤러로 나눠서 개발을 진행하면 각 컴포넌트는 자신의 결과만 다른 컴포넌트로 넘겨주면 되기 때문에 결합도를 낮출 수 있으며 유지보수 할 경우에도 특정 컴포넌트만 작업하면 되기 때문에 쉽게 보완이 가능하다.

 

MVC 한계점 💁🏻‍♂️

출처 : https://www.infoq.com/news/2014/05/facebook-mvc-flux/

세상에는 완벽한 sw는 없다!

✏️ MVC에도 문제점이 존재한다. 다음 MVC 패턴을 보면 양방향 데이터 흐름이기에 복잡한 대규모 프로젝트의 경우 View와 Model 사이의 의존도가 높아지며 불필요하게 컨트롤러가 커지는 현상이 발생한다.

 

💁🏻‍♂️ 무슨말인지 이해가 되지 않습니다!

• 위의 그림을 다시 한번 보자! 모델이 업데이트 되면 뷰 화면에 반영이 된다. 뷰 또한 모델을 업데이트 할 수 있기 때문에 업데이트된 뷰가 다른 모델을 업데이트 한다면 계속해서 이런식으로 데이터가 흘러가며 복잡해진다.

 

Flux 만세 ❗️

출처 : https://www.infoq.com/news/2014/05/facebook-mvc-flux/

✏️ MVC패턴이 복잡해지면서 발생한 Massive-View-Controller 현상을 해결하기 위해서 Facebook에서 Flux 패턴을 만들었다.

Flux패턴은 양방향이 아닌 단방향 데이터 흐름의 방식이다.

데이터의 흐름을 쉽게 보자면 항상 Dispatcher → Store → View, View는 Action을 통해서 다시 Dispatcher로 데이터가 이동한다. 이러한 단방향 데이터 방식은 예측하기 보다 더 쉽게 만드는 장점을 가지고 있다.