MVC 아키텍처의 책임 분할 원칙

저는 최근 Yii 프레임워크의 MVC 프레임워크를 사용하는 프로젝트를 담당했습니다. 처음에는 구조가 매우 견고하다고 생각했습니다.

하지만 비즈니스 로직에 대한 이해가 깊어지면서 문제의 심각성을 깨닫기 시작했습니다.

MVC의 컨트롤러를 오해하고 과거의 경험을 토대로 모든 비즈니스 로직이 컨트롤러의 액션에 구현되어 있다고 당연하게 여겼습니다.

결과적으로 각 컨트롤러에는 수천 줄의 코드가 포함되어 점점 더 비대해지고 있습니다.

드디어 코드를 리팩터링하기로 마음먹었습니다. API 인터페이스를 외부 세계에 개방해야겠다는 생각이 그 시작이었습니다.

현재 아키텍처에 따르면 코드는 기본적으로 재사용이 불가능합니다. 많은 기능을 다시 작성해야 하는데 이는 정말 용납되지 않습니다.

객체지향 프로그래밍은 단순히 교과서에 나오는 용어가 아닙니다!

연습을 시작하고 나서야 객체지향적 인식과 전체적인 시각을 갖는 것이 얼마나 드문 일인지 깨달았습니다.

MVC 디자인 원칙

1. 정확히 무엇인가요? 🎜🎜#

MVC(Model-View-Controller)는 디자인 프레임워크(디자인 패턴)입니다.

MVC의 목표는 비즈니스 로직을 사용자 인터페이스 고려 사항과 분리하는 것입니다.

이렇게 하면 개발자는 다른 부분에 영향을 주지 않고 각 부분을 더 쉽게 변경할 수 있습니다.

MVC에서 모델은 데이터와 비즈니스 규칙을 나타냅니다. 뷰에는 텍스트, 양식 등과 같은 사용자 인터페이스 요소가 포함되어 있습니다. 컨트롤러는 모델과 뷰 간의 통신을 관리합니다.

MVC는 다양한 프로그래밍 언어로 구현됩니다. 예를 들어 J2EE 애플리케이션 개발에서

View는 jsp로 구현될 수 있습니다. 컨트롤러는 이제 일반적으로 Struts로 구현됩니다. 모델은 엔터티 Bean에 의해 구현됩니다.

2. 어떤 문제가 발생했나

Yii Framework는 Ruby on Rails의 ActiveRecord(AR) 개념을 기반으로 하는 인기 있는 PHP 프레임워크입니다. .

데이터베이스의 모든 테이블은 AR 클래스를 사용하여 추가, 삭제, 수정 및 쿼리 작업을 쉽게 수행할 수 있습니다.

AR을 모델로 취급하며 모델이라는 디렉터리에 배치하는 것을 권장합니다.

그래서 테이블에 해당하는 AR을 자동으로 생성한 후에는 이미 Model 레이어가 있다고 당연하게 여겼습니다.

사실 AR은 모델 레이어가 아닌 DAO(데이터 액세스 레이어)일 뿐입니다.

사용자가 제출한 양식에 대한 다양한 논리적 판단, 계산 수행, AR 인스턴스화를 통해 데이터 저장 등 거의 모든 업무가 컨트롤러에 배치됩니다...

#🎜🎜 #왜냐하면 컨트롤러에는 여러 작업이 있으며 각 작업에는 이러한 비즈니스 처리가 있습니다.

드디어 컨트롤러 코드가 1000줄을 초과한 것을 발견했습니다.

갑자기 리더는 우리 시스템이 기존의 기존 시스템에 대해 API를 개방하여 타사 인터페이스를 호출하고 제공해야 한다고 말했습니다.

제3자는 매개변수만 제공하면 되며, 이 시스템은 결과 값만 제공하므로 비즈니스 처리에는 관심이 없습니다.

나쁜 점은 컨트롤러가 이미 해당 서비스를 구현했지만 양식 제출을 허용한다는 것입니다. 어떻게 SOAP xml 문서도 허용할 수 있습니까?

컨트롤러는 콘돔과 마찬가지로 최대한 얇아야 합니다.

그 책임은 사용자 입력을 수락한 다음 처리를 위해 즉시 다른 카테고리로 전달하는 것입니다.

이런 방식으로 Controller는 서로 다른 인터페이스를 제공하는 역할만 담당하므로 비즈니스 로직을 분리할 수 있고 분리된 비즈니스를 쉽게 재사용할 수 있습니다.

이 사업의 분리된 부분은 누가 처리하나요? 대답은 모델이어야합니다.

3. View의 책임

View 부분은 상대적으로 명확하며, 디스플레이를 담당합니다.

디스플레이 인터페이스와 관련이 없는 모든 항목은 뷰에 표시되어서는 안 됩니다.

따라서 복잡한 판단문과 복잡한 계산 과정은 일반적으로 View에 나타나지 않아야 합니다.

간단한 루프 문과 서식 지정 문을 사용할 수 있습니다. 예를 들어 블로그 홈페이지의 텍스트 목록은 일종의 루프입니다.

PHP 웹 애플리케이션의 경우 HTML이 View의 주요 콘텐츠입니다.

View는 Model의 쓰기 메서드를 호출하면 안 됩니다.

즉, View는 Model에서 데이터를 읽기만 하고 Model을 다시 작성하지는 않습니다.

그래서 View와 Model은 분리될 수 없다고 말합니다.

또한 $_GET 및 $_POST는 View에서 직접 액세스할 수 없으며 컨트롤러를 통해 View로 전달해야 합니다.

또한 View에는 일반적으로 데이터베이스 쿼리 등 데이터 처리를 준비하는 콘텐츠가 없습니다.

이것들은 일반적으로 컨트롤러에 배치되고 변수 형태로 뷰에 전달됩니다.

즉, 뷰에 사용되는 데이터가 변수입니다.

4. 모델의 책임

모델에게 가장 중요한 것은 정보를 저장하고 출력하는 것입니다.

예를 들어 Post 클래스에는 블로그 게시물의 제목을 저장하는 데 사용되는 title 속성이 있어야 하며, 모델의 모든 내용인 삭제 작업이 있어야 합니다.

데이터, 동작, 메소드가 모델의 주요 내용입니다.

실제 작업에서 Model은 MVC에서 가장 많은 양의 코드를 가지고 있습니다.

모델은 로직에서 가장 복잡한 부분입니다. 애플리케이션의 비즈니스 로직도 여기에 표현되어야 하기 때문입니다.

모델과 컨트롤러 구별에 주의하세요.

Model은 비즈니스 로직을 처리하고 Controller는 단순히 Model과 View 간의 관계를 조정합니다.

비즈니스와 관련된 것이라면 모델에 넣어야 합니다.

데이터 검증, 공개 상수 및 변수는 모두 모델 레이어에 배치되어야 합니다.

즉, 재사용할 수 있는 속성이나 메서드는 모델 레이어에 배치되고 한 번 정의되어 어디에서나 사용되어야 합니다.

모델은 요청, 세션 및 기타 환경 데이터에 액세스해서는 안 되며 컨트롤러에 의해 주입되어야 합니다.

좋은 디자인은 뚱뚱한 모델과 얇은 컨트롤러가 있어야 합니다.

5. 컨트롤러의 책임

컨트롤러는 주로 사용자 요청에 응답하고, 어떤 뷰를 사용할지, 어떤 데이터를 준비해야 할지 결정합니다.

따라서 요청에 대한 액세스 코드는 $_GET, $_POST 등과 같이 컨트롤러에 배치되어야 합니다.

컨트롤러는 사용자 요청 데이터를 얻는 것으로 제한되어야 하며 데이터에 대한 작업이나 전처리를 수행해서는 안 됩니다. 이는 모델 내에 배치되어야 합니다.

데이터 쓰기 작업을 완료하려면 Model 클래스의 메서드를 호출해야 합니다.

사용자 요청에 따라 뷰 렌더링이 호출됩니다.

또한 일반적으로 HTML 코드나 기타 프레젠테이션 레이어 항목이 없어야 하며 이는 뷰의 콘텐츠여야 합니다.

6. Enlightenment

Yii Framework의 공식 문서에는 다음 단락이 있습니다.

In a well-designed MVC application, controllers are often very thin, containing probably only a few dozen lines of code; while models are very fat, containing most of the code responsible for representing and manipulating the data.

간단히 말하면 Rich Model is Better입니다.

위 내용은 MVC 아키텍처의 책임 분할 원칙의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!