그렇습니다! 이별은 더 나은 만남을 위한 것! Model은 데이터 작업 방법의 집합입니다. Controller는 Model 메서드 호출과 View에 대한 응답을 담당합니다. 대형 프로젝트의 특징은 데이터 흐름이 크고 복잡하며 데이터 작업 방법이 분리되지 않는다는 것입니다. Controller(Coupling)에 분산되어 있으면 페이지 데이터의 동작을 전체적으로 제어할 수 없으며 유지 관리 및 재사용이 어렵습니다. 별도로, 모델은 메소드만 노출합니다. 이때 모델은 데이터를 생성하는 기계로 간주할 수 있습니다. 컨트롤러에서 해당 메소드와 매개변수를 호출하면 해당 데이터가 메소드 내부로 반환됩니다. 컨트롤러에 투명합니다(디커플링). 모델은 유지관리 및 재사용도 용이하며, 요청한 URL까지 분리하여 별도로 관리할 수 있습니다.
그러면 페이지 요청이 늘어나나요?
프론트엔드 엔지니어링에서는 빌드 도구를 필연적으로 언급하므로 도구의 도움을 받아 함께 패키징할 수 있습니다.
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
모델과 컨트롤러에 대해 두 개의 별도 .js 파일을 작성해야 합니까?
그렇습니다! 이별은 더 나은 만남을 위한 것!
Model은 데이터 작업 방법의 집합입니다. Controller는 Model 메서드 호출과 View에 대한 응답을 담당합니다.
대형 프로젝트의 특징은 데이터 흐름이 크고 복잡하며 데이터 작업 방법이 분리되지 않는다는 것입니다. Controller(Coupling)에 분산되어 있으면 페이지 데이터의 동작을 전체적으로 제어할 수 없으며 유지 관리 및 재사용이 어렵습니다. 별도로, 모델은 메소드만 노출합니다. 이때 모델은 데이터를 생성하는 기계로 간주할 수 있습니다. 컨트롤러에서 해당 메소드와 매개변수를 호출하면 해당 데이터가 메소드 내부로 반환됩니다. 컨트롤러에 투명합니다(디커플링). 모델은 유지관리 및 재사용도 용이하며, 요청한 URL까지 분리하여 별도로 관리할 수 있습니다.
그러면 페이지 요청이 늘어나나요?
프론트엔드 엔지니어링에서는 빌드 도구를 필연적으로 언급하므로 도구의 도움을 받아 함께 패키징할 수 있습니다.
답변, 코드가 없습니다. 오류가 있으면 지적해주세요 :)
@kraaas님이 이미 답변해주셨으니 더 말씀드릴게 없습니다.
모델과 컨트롤러가 컨셉으로 떠오를 때, 분리되든 말든 무슨 상관인가요? 코드를 기계가 읽을 때 분할 여부가 무슨 상관이겠는가? 문제는 프로그램을 기계가 읽도록 작성한 것이 아니라 그대로 읽는 것이 편리하다는 점이다. 분명히 이별은 일종의 더 나은 선택입니다.