개인적으로는 원래의 비즈니스 로직 코드나 별도로 구현할 복잡한 비즈니스 로직 코드를 클래스 라이브러리로 추출해야 한다고 생각합니다.
MVC는 주로 뷰, 모델, 사용자 제어의 분리를 해결합니다. 실제 비즈니스 시나리오에서는 다중 테이블 공동 쿼리, 트랜잭션 프로세스 처리 등과 같은 보다 복잡한 논리적 처리가 필요할 수 있습니다. 이러한 복잡하고 상대적으로 독립적이며 보기 독립적인 비즈니스 논리 코드는 별도의 클래스 라이브러리로 추출되어 외부 인터페이스를 제공할 수 있습니다. MVC에서 종속성 주입 또는 직접 참조를 통해 호출됩니다. MVC의 M은 단지 도메인 모델의 역할을 수행하므로 더 좋을 수도 있습니다.

이런 질문을 보니 "바보야, 바보야, JB가 무슨 질문을 하는 거야?"라고 말하고 싶었는데, 생각해보니 어찌됐든 참아야겠다는 생각이 들었다. .여기서 묻고 싶은 것은 당신이 기반으로 하고 있는 비즈니스 로직이나 기반은 무엇입니까? 왜 이런 일을 하는가? 이 일을 하면 어떤 이점이 있다고 생각하시나요? 이를 통해 귀하의 아이디어를 분석하고 답변할 수 있습니다. 그렇지 않으면 대부분의 사람들은 맥락 없이 질문에 답변하고 싶어하지 않으며, 특히 기술 분야에 종사하는 사람들은 이유를 알고 싶어하며 자연스럽게 그것이 불합리하다고 생각할 것입니다. 나는 당신을 꾸짖을 것입니다. 아아, 여기서는 한 가지만 언급하고 싶지 않습니다. 다른 세 가지 레이어를 모델에 넣으면 모델이라고 부르지 않으며 상황에 따라 호출되지도 않습니다. , 설명 할 수 없습니다.

하하 포스터는 표현력에 문제가 있는 것 같아요

프로젝트의 다른 세 레이어를 모델에 통합하는 방법은 무엇인가요?

이렇게 하는 것은 비과학적입니다. MVC는 다른 것을 분리하는 것입니다.

아 이렇게 하면 굳이 레이어할 필요가 없는데 왜 아직도 MVC가 필요하냐...

당신은 외계인입니다. . . .

2B 아직도 무시하시는데 명확하게 물어보실 수 있나요?

mvc의 개념을 알 수 있습니다