모든 분야에는 상술이 있다.
뭔가 유명해져서 돌아다니고 있다면, 그 이면에는 상술이 있다.
그래서 이해하기 힘든 인정하기 힘든 개념들이 간혹 존재한다.
그중 하나가 MVC패턴이다.
이상하지 않은가?
우리는 웹을 개발할때 분명
view = 디자인 이쁘게 꾸미고, 사용 편리하게 하기
function = 기능 구현하기
DB = DB에 저장하고 불러오기
이렇게 3가지를 반복하면서 구현 한다.
그런데, MVC는 뭘까?
Model = 데이터 규격화 주로 타입지정(협업에서 실수하지 않기 위해 객체지향의 거름정도)
view = view는 기존 sigle 로 한페이지에 다 넣지 말자, spa나 앱처럼 분리
controller = function + DB + ROUTER?
나도 한동안 model 이 규격보다는 DB 쿼리 날리는 곳인줄 알고 썼다.
그런데, Model 은 이름 그대로 구조화 규격화 하는 곳이다.
controller 은 기능과 DB쿼리가 공존하는 곳 같은데, 라우터 설정은 별도 파일로 해주어서 controller 목은 아닌것 같고
잘 살펴보면
해깔리는 주요 원인은 DB쿼리에 대한 책임이 이 패턴에서 빠져있기 때문이다.
왜 요따구로 패턴이라면서 만들어 놓았을까 바로 SAAS 서비스들 때문이다.
서버리스 서비스들이 자신들 이용하라고 하면서 패턴 이야기하고 툭 DB 부분을 빼버린거다.
MVQC 이렇게 구체적으로 분리해서 만들고 설명해야 쉽게 이해 된다.
model이나 controller에 Q쿼리를 넣으면 복잡해 보여서 코드가 직관적으로 들어오지 않는다. 그래서 MVC 영향 받은 기성 프레임워크는 개념으로는 MVQC 이렇게 분리해서 생각하고 Q를 MODEL 에 넣을지 CONTROLLER에 넣을지 아니면 따로 뺄지 등을 고민하면 된다.
GO나 RUST로 개발하려면 속도나 안정성등의 이점으로 SAAS를 이용하는 것 이상의 비용절감이 가능한데, 이동네애서는 QUERY를 좀더 구체화시켜서 사용하는 분위기다.
참고로 GRAPHQL은 쿼리가 VIEW에 있는 거다. DB QUERY가 중요한데, 자기 자리도 찾지 못하고 찬밥신세가 되었다. DBA라는 직업도 있는데 개념에서 아예 거론도하지 않는다.
대기업들의 기만이 우리를 해깔리게 한다.
그래서 처음 개발 배우는 분들이 많이 해깔린다.
MVC아니다. MVQC다. Q가 어디있는지 잘 파악해야 한다.
숨은 Q를 잘 찾아야 한다.
