MVC
DOM 조작 메소드 (createElement, appendChild etc.)를 통해 만들게 되면, 일명 Spaghetti code(실타래 코드)로, 한번꼬이면 대책이 없으며 오류가 찾기 어려운 코드로 만들수밖에 없게 된다.
이러한 문제를 없애기 위해 나온것이 MVC 코드이다. innerHTML과 템플릿 리터럴 방식을 사용하여 템플릿을 만들어 바인딩을 시켜주는것이 innerHTML이다.
MVC - Model(화면에 출력할 변수) View(모델을 컨트롤러로 조작을 하여 화면에 보이게끔 함.) Controller(모델을 조작)
즉, MVC는 각 역할(모델이면 모델, 컨트롤러면 컨트롤러, 뷰면 뷰 역할)을 세분화해서 만드는 디자인 패턴이다.
모델이 변수를 꽃아넣을 곳, 뷰가, jsx, controller은 모델을 제어하는 함수
Angular이 MVC의 최초 라이브러리였으며, Vue가 이후에 나오게 됐다.
React는 MVC가 아니며, Flux 패턴을 사용한다. Model -> State라는 용어로 바뀜.
Angular.js의 탄생배경
이전에 자바스크립트와 AJAX가 사용되기 전에는 HTML기능만을 사용하여 화면을 구성하였다. 이때, 클라이언트 측에서는 매번 서버한테 페이지 요청을 했어야했으며, 이러한 방식을 SSR(Server-Side Rendering)이라고 한다. 이러한 방식은 페이지 로딩 시간이 오래 걸리며, 사용자 경험이 좋지 않았다.
이러한 문제점 때문에 자바스크립트 사용과 AJAX가 도입되어 SPA(Single Page Application)이 등장하였다. 이는 페이지 로딩 시간이 줄어들고, 사용자 경험이 좋아졌다. 하지만, 이러한 방식은 데이터 처리가 복잡해지면서 데이터 처리 로직이 복잡해졌다
특히, DOM 조작이 많은 경우에는 데이터 처리 로직이 복잡해지면서 코드의 가독성이 정말 떨어졌으며, 유지보수가 어려워졌다.
Google에서는 Feedback 프로젝트를 진행하면서 17000줄이라는 방대한 코드를 작성하게 됐으며, 이러한 문제점을 해결하기 위해 Misko Hevery가 자신만의 라이브러리를 만들어 해당 코드를 약 1500줄로 줄이는 엄청난 성과를 내었으며, 해당 라이브러리가 바로 Angular.js이다.
이후로는 수백개의 구글 프로젝트가 Angular.js를 사용하게 되었으며, MVC, MVP, MVVM, PM 등 다양한 패턴이 등장하게 되었으며, 이를 MVW(Model-View-Whatever)라고 부르게 되었다.
하지만 이러한 앵귤러도 앵귤러2가 나오면서 쓴맛을 맛보게 되었다. 앵귤러2는 기존버전과 호환이 되지 않는다는 큰 문제점을 가지고 있었으며, Node.js, Typescript 등 학습량이 너무 많아 사용자들이 혼란을 겪게 되었다. 그래서 이후에 Vue, React 등의 라이브러리가 대중화되면서 앵귤러의 점유율은 점차 떨어지게 되었다.
Vue
Vue는 앵귤러와 같은 MVC패턴을 사용하는 라이브러리이다.
MVC는 기본적으로 무조건 템플릿이 마련되어 있다. 모델을 꽃아 넣는 행위를 바인딩이라고 불린다. 프레임워크 마다 바인딩 하는 구문은 각자 다르다.
MVC는 라이브러리가 아닌 방법론으로, php, jsp등에서도 존재한다.
MVC패턴을 사용할때, querySelector을 통해 dom요소를 접근할때, 일일이 document 객체에 접근하지 말고, root가 되는 요소를 document로 접근한 후, 그 이후 가져온 요소에서 부터 querySelector를 사용하자. (이는 아이디의 중복을 최대한 방지하기 위해서임. )
Flux
문제점이 없을 것만 같던 MVC 패턴도 여러가지 문제점을 가지고 있었다.
- 데이터 흐름이 양방향이다. (양방향 바인딩)
- 데이터 흐름을 파악하기 어렵다.
- 데이터 흐름을 통제하기 어렵다.
특히, 양방향 바인딩은, 복잡한 상태관리가 필요한 대규모 애플리케이션에서는 데이터 흐름을 파악하기 어렵고, 데이터 흐름을 통제하기 어렵다는 문제점이 있었다.
flux패턴이 등장하게 된 배경이 된 투웨이 바인드의 단점을 더 자세히 알아보자.
상태 중첩 및 관리가 복잡해질 수록 양방향 바인딩은 코드를 알아보기가 너무 힘들고 무한루프가 발생하게 된다. (채팅 시스템, 안읽은 메시지, 메시지 확장 화면, 팝업)
이러한 문제점을 해결하기 위해 페이스북에서는 단방향 패턴인Flux 패턴을 발표하게 됨.
Flux 패턴은 Action, Dispatcher, Store, View 4가지 요소로 이루어져 있다.
React는 이러한 Flux 패턴을 사용하여 데이터 흐름을 통제하고, 데이터 흐름을 파악하기 쉽게 만들어주었다. Flux 패턴은 데이터 흐름이 단방향이며, 데이터 흐름을 파악하기 쉽고, 데이터 흐름을 통제하기 쉽다는 장점이 있다.
그래서 si업체, 이커머스 서비스에서는 mvc패턴이 유리하다. (사용자 입력외에는 잘 안들어오기 때문에) 소셜, ott 등 서비스를 개발하는 업체들은 이처럼 flux패턴을 사용하게 된다.
이커머스가 MVC에 유리한 이유
- 데이터 흐름의 단방향성
- 상품정보, 가격, 재고 등은 대부분 서버 -> 클라이언트로 전달
- 사용자의 액션(주문, 결제 등)도 명확한 프로세스를 따름
- 트렌젝션 중심의 처리
- 주문, 결제, 재고 관리 등이 CRUD 작업 중심
- 데이터의 일관성과 무결성이 매우 중요
- Controller를 통한 중앙 집중식 처리가 용이함
- 상태 관리의 단순성
- 대부분의 상태가 서버측에서 관리
- 클라이언트의 상태는 비교적 단순(장바구니, 주문 단계)
OTT/소셜 서비스가 Flux패턴이 유리한 이유
- 복잡한 상태 관리
- 실시간 업데이트가 빈번(좋아요, 댓글, 스트리밍 상태 등)
- 여러 컴포넌트가 동일한 데이터를 공유
- 상태 변화가 다른 여러 부분에 영향을 미치게 됨.
- 양방향 데이터 흐름
- 사용자 인터렉션이 매우 활발하게 일어남.
- 실시간 데이터 동기화 필요
- 여러 사용자의 동시 액션 처리
- 단방향 데이터 흐름의 장점
- 예측 가능한 상태 관리
- 디버깅이 용이
- 상태 변화 추적이 쉬움
- 비동기 처리의 용이성
- 스트리밍 데이터 처리
- 실시간 알림
- 소켓 통신
flux에서는 mvc패턴에서 양방향 바인딩의 문제가 됐던 변수간의 상태 충돌을 막기 위해 set함수들을 통해 state를 관리해야하는 것 또한, document객체를 사용하지 않는 mvc와 달리 이벤트객체를 사용하는 것이 특징 (원웨이 바인딩만 지원하기 때문이다. )