표준 MVC는 컨트롤러에서 직접 비즈니스 로직을 구현하지만 실제 프로젝트에서는 여전히 컨트롤러와 데이터베이스 작업 사이에 서비스 계층을 캡슐화하는 것이 좋습니다. 컨트롤러는 다양한 요청 URL에 응답하므로 기능면에서 중복이 많이 발생합니다. 반면에는 서비스 기능이 향후 다른 애플리케이션 입력이나 다른 터미널(예: APP, 모바일 H5 등)과 같은 다른 프런트엔드에 노출될 수도 있습니다.
지금 맡은 프로젝트의 Controller 레이어도 엄청나게 큽니다. 한 가지 방법은 수백 줄이고 if 중첩 레이어가 여러 개 있어서 가장 큰 문제는 매우 번거롭다는 것입니다. 이전 비즈니스 논리를 이해해야 합니다. 개인적으로 더 좋은 방법은 특정 논리 작업을 담당하는 서비스가 있다고 생각합니다. 가능합니다. 코드는 최대한 확장 가능해야 합니다.
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
표준 MVC는 컨트롤러에서 직접 비즈니스 로직을 구현하지만 실제 프로젝트에서는 여전히 컨트롤러와 데이터베이스 작업 사이에 서비스 계층을 캡슐화하는 것이 좋습니다.
컨트롤러는 다양한 요청 URL에 응답하므로 기능면에서 중복이 많이 발생합니다.
반면에는 서비스 기능이 향후 다른 애플리케이션 입력이나 다른 터미널(예: APP, 모바일 H5 등)과 같은 다른 프런트엔드에 노출될 수도 있습니다.
매우 안타깝습니다. 확장이 매우 어렵고 유지 관리성도 매우 좋지 않습니다.
컨트롤러는 얇은 레이어여야 하며, 비즈니스 로직은 가능한 한 서비스 레이어에 배치되어야 서비스 세분화 및 서비스 활용 측면에서 더욱 자유로워야 합니다.
물론 좋지는 않습니다. 컨트롤러 계층은 비즈니스 데이터 상호 작용만 담당하고 비즈니스 로직은 서비스 계층에서 처리합니다.
지금 맡은 프로젝트의 Controller 레이어도 엄청나게 큽니다. 한 가지 방법은 수백 줄이고 if 중첩 레이어가 여러 개 있어서 가장 큰 문제는 매우 번거롭다는 것입니다. 이전 비즈니스 논리를 이해해야 합니다. 개인적으로 더 좋은 방법은 특정 논리 작업을 담당하는 서비스가 있다고 생각합니다. 가능합니다. 코드는 최대한 확장 가능해야 합니다.
으아악
서비스에 배치되어도 여전히 엉망입니다. . 복잡한 비즈니스 상황과 열악한 코드 유지 관리 가능성을 피하려면 여전히 다른 방법이 필요합니다
오늘 동료에게 코드를 보도록 하세요. 그가 가장 먼저 말한 것은 컨트롤러 코드를 서비스에 넣어야 한다는 것이었습니다.=_=;
주로 비즈니스의 복잡성에 따라 다릅니다. 매우 간단한 비즈니스이므로 컨트롤러부터 서비스까지 전체 팀의 개발 사양에 따라 달라집니다.