저도 비슷한 의심을 한 적이 있습니다. 사실 다들 얇은 컨트롤러가 뚱뚱한 모델이라고 했는데, 왜 얇은 컨트롤러가 뚱뚱한 모델이어야만 할까요? 뚱뚱한 모델이 우리의 디자인 원칙을 위반하는 것 아닌가요?

그래서 이 문제에 대한 내 해결책은 살을 빼고 싶으면 모두가 살을 빼야 한다는 것입니다. 얇은 컨트롤러 + 얇은 모델 검증 레이어(나는 이것을 model_service라고 부릅니다) + 얇은 모델, 이 경우에는 여러 컨트롤러를 재사용하더라도 검증 레이어는 문제가 되지 않으며 모델은 여전히 기본적인 추가, 삭제, 수정 및 확인이며 이 모델은 더 유연할 것입니다. 예를 들어 일반적인 문제는 하나의 모델이 추가, 삭제, 수정 및 확인을 참조한다는 것입니다. 다른 모델도 확인하고 바로 재사용도 가능해요

사실 레이어링은 아이디어라고 해서 꼭 정해진 계획을 따라야 하는 것은 아닙니다. 그런 경우에는 레이어링이라는 아이디어를 채택했으므로 상관없습니다. mvc 또는 smvc 중 어느 것이 더 나은지는 프로그램이 어떻게 계층화되어 있는지에 따라 달라집니다. 어쩌면 계층화 계층화를 위해 xxxmvc 계층화 설계를 생각해 냈을 수도 있습니다. 계층을 추가할 수 있는 설계 고려 사항이 있어야 한다는 점을 기억하십시오.

인터넷에서 "컴퓨터 과학 분야의 모든 문제는 간접 중간 계층을 추가하면 해결될 수 있다"라는 말이 유행했던 것으로 기억하는데, 프록시, 캐시, CGI, 팩토리 등 유사한 개념을 많이 볼 수 있을 것입니다. 모드 등. '중간 레이어'라는 개념도 있는데, 연관된 두 레이어 중 어느 레이어에 넣어도 좋다고 생각하면 중간 레이어를 두는 게 낫지 않을까 하는 생각도 들 수 있지 않을까?

레일즈 경험에 따르면 모델에 쓰는 것이 더 좋습니다

레일에는 뚱뚱한 모델과 얇은 컨트롤러라는 말이 있습니다
레일스 예:

Person 모델은 first_name, last_name 필드의 유효성을 검사합니다

JSR-303 Bean Validation API를 참고하세요. 또한 hibernate-validation jar 라이브러리는 모델에 작성되고 주석을 사용하는 검증 표준도 확장합니다.