MVC 웹 애플리케이션에서 이러한 시나리오에서 컨트롤러는 무엇입니까?

Question

1) 웹 사이트의 홈페이지는 "컨트롤러"에 어디에 적합합니까? 나는 어떤 사람들이 "페이지"컨트롤러를 사용하여 집, 연락처 등과 같은 정적 페이지를 처리하는 것을 보았지만, 나에게 이것은 좋은 생각처럼 보이지 않습니다. 홈페이지를위한 독특한 컨트롤러를 만드는 것이 더 나은 옵션이 될까요? 결국, 여러 모델에 액세스해야 할 수도 있으며 일부 사람들이 사용하는 모델 이론 당 하나의 컨트롤러 전체와 잘 어울리지 않습니다.

2) 여러 유형의 사용자를위한 대시 보드가 필요한 경우, 어떤 사용자에 따라 코드를 토글하는 대시 보드 컨트롤러일까요? 예를 들어 관리/대시 보드, 계정/대시 보드 등

3) 전체 간단한 CRUD 예제를 사용하면 컨트롤러를 설명하려고 할 때 매력처럼 작동하지만 간단한 기능을 지나면 컨트롤러가 고장날 수있게 될 수 있습니다. 어떤 사람들은 사용자 컨트롤러에서 로그인 기능을 할 때 로그인 컨트롤러를 작성하도록 선택하는 이유는 무엇입니까? 내가 생각하는 한 가지 이유는 우리 중 많은 사람들이 페이지 접근 배경에서 나오고 컨트롤러를 "개체"또는 "명사"로 생각하기가 어렵 기 때문입니다. 페이지가 항상 그런 식으로 작동하지 않기 때문입니다. 지구상에서 왜 "페이지"컨트롤러를 만들고 싶을까요? 나에게 옳지 않은 것 같습니다.

4) 컨트롤러는 동작을 수행 할 수있는 "개체"보다 유스 케이스와 더 관련이 있어야합니까? 모든 집중적 인 목적으로 전체 앱에서 모든 작업을 수행하는 사용자 컨트롤러를 만들 수 있습니다. 또는 일부 사람들이 말하는 것처럼 "관심 영역"당 컨트롤러를 만들 수 있습니다. 또는 원하는 경우 뷰 당 하나의 컨트롤러를 만들 수 있습니다. 여유가 너무 많아서 일관된 방법을 알아 내기가 어렵습니다.

컨트롤러는 아마도 혼란스럽지 않아야하지만 어떤 이유로 그들은 나에게서 지옥을 당황하게합니다. 도움이되는 의견은 대단히 감사하겠습니다.

Answer 1

1) 나는 일부 MVC 물건에 간단한 홈브류 클래스 세트를 사용하며 컨트롤러 이름을 동작 및보기 이름과 관련시킵니다 (Zend와 유사한 전면 컨트롤러 스타일). 일반 웹 사이트의 경우 홈페이지, 개인 정보 보호 정책, 연락처 페이지 및 정보 페이지가 있다고 가정 해 봅시다. 나는이 모든 것들에 대해 별도의 컨트롤러를 만들고 싶지 않으므로 내 안에 붙일 것입니다. IndexController, 기능 이름과 같은 기능이 있습니다 actionIndex(), actionPrivacy(), actionContact(), 그리고 actionAbout().

그와 함께, 내보기 디렉토리 안에는 각 동작과 관련된 템플릿 디렉토리가 있습니다. 기본적으로 모든 작업에서는 ASTEAT가 관련 템플릿을 자동으로 찾으려면 원하는 경우 하나를 지정할 수 있습니다. 그래서 actionPrivacy() 템플릿 파일을 찾을 것입니다 index/privacy.php, actionContact() 찾을 것입니다 index/contact.php, 등.

물론 이것은 URL과 관련이 있습니다. 그래서 URL이 쳤다 http://www.example.com/index/about 실행할 것입니다 actionAbout(), About Page 템플릿을로드합니다. About Page는 완전히 정적 콘텐츠이므로 내 actionAbout() 프론트 컨트롤러가보고 실행할 수있는 공개 조치를 제공하는 것 외에는 아무것도하지 않습니다.

따라서 귀하의 질문의 핵심에 답하기 위해 여러 "페이지"를 단일 컨트롤러에 넣고 목적에 맞게 잘 작동합니다. 컨트롤러 당 하나의 모델은 Web MVC와 함께 작업 할 때 따라야한다고 생각하지 않는 이론입니다.

2) 이를 위해 여러 컨트롤러가 있습니다. 위에서 사용하는 것과 동일한 방법을 따라 /admin/dashboard 그리고 /account/dashboard 당신이 제안한 바와 같이, 이유는 없지만, 그들은 같은 (또는 동일한 부분) 템플릿을 사용할 수 없었습니다.

다른 종류의 사용자가 다른 종류의 사용자를 가지고 있다면 더 일반적인 것을 만들고 하나의 컨트롤러 만 사용하고 로딩을 처리하기 위해 mod_rewrite 규칙을 가지고 있다고 생각합니다. 아마도 대시 보드의 기능적으로 복잡한 방법과 계정 설정이 어떤지에 따라 다를 수 있습니다.

3) CRUD 기능은 MVC의 모든 계층으로 직접 구현하기가 어렵고 여전히 깨끗하고 유연하며 효율적입니다. 나는 crud 기능을 모든 객체가 호출 할 수있는 서비스 계층으로 추상화하고 Crud가 필요한 객체를 확장 할 수있는 기본 객체 클래스를 갖는 것을 좋아합니다.

CRUD를 위해 PHP ORM 프레임 워크를 사용하는 것이 좋습니다. 그들은 좋은 구현을 얻는 많은 번거 로움을 해결할 수 있습니다.

로그인 컨트롤러 대 사용자 컨트롤러와 관련하여 응용 프로그램 도메인에 따라 다릅니다. 내 스타일의 프로그래밍을 사용하면 사용자 모델 도메인 내에서 간단한 작업으로 "로그인"을 생각하는 경향이 있으므로 사용자 컨트롤러 내부에 단일 작업이 있습니다. 더 정확히 말하면, 나는 가질 것이다 UserController 사용자 모델을 인스턴스화하고 모델에서 로그인 루틴을 호출하십시오. 나는 이것이 올바른 방법이 무엇인지 확신 할 수 없었기 때문에 이것이 올바른 방법이라고 말할 수 없다. 맥락의 문제입니다.

4) 당신은 여유에 대해 옳습니다. 앱/사이트가 원하는 모든 것을 처리 한 컨트롤러를 쉽게 만들 수 있습니다. 그러나 나는 이것이 유지 보수 악몽이 될 것이라는 데 동의 할 것이라고 생각합니다. 나는 여전히 시장 연구 회사에서의 마지막 직업에 대해 지식-지브 블리를 생각하게합니다. 여기서 내부 PHP 앱은 해외 팀이 제가 훈련을 거의하지 않았다고 가정 할 수있는 것만으로 수행되었습니다. 우리는 전체 사이트를 처리 한 10,000 개의 라인 스크립트에 대해 이야기하고 있습니다. 유지하는 것은 불가능했습니다.

따라서 앱/사이트를 비즈니스 도메인 영역으로 나누고이를 기반으로 컨트롤러를 작성하는 것이 좋습니다. 앱의 핵심 개념을 파악하고 거기에서 이동하십시오.

예시

분명히 Rock을 관리하기 때문에 Manatees에 관한 웹 사이트가 있다고 가정 해 봅시다. 일반 사이트 페이지 (약, 연락처 등), 사용자 계정 관리, 포럼, 사진 갤러리 및 연구 문서 자료 영역 (Manatees에 대한 최신 과학)을 원합니다. 매우 간단하고 많은 것이 정적이지만 고장을보기 시작할 수 있습니다.

IndexController - 페이지, 개인 정보 보호 정책, 일반적인 정적 콘텐츠에 대한 처리.

UserController - 계정 생성, 로그인/아웃, 환경 설정 처리

PictureController - 그림을 표시하고 업로드를 처리합니다

ForumController - 아마도 많지 않을 것입니다. 외부 포럼을 통합하려고 노력할 것입니다. 여기에는 많은 기능이 필요하지 않을 것입니다.

LibraryController - 최근 뉴스 및 연구 목록을 보여줍니다

HugAManateeController -HTTP보다 실시간으로 포옹하는 가상 해우

그것은 아마도 당신에게 최소한 기본적인 분리를 줄 것입니다. 컨트롤러가 극도로 커지면 비즈니스 도메인을 별도의 컨트롤러로 분류 할 때가되었습니다.

모든 프로젝트마다 다를 것이므로 약간의 계획은 어떤 종류의 건축 구조를 향해 먼 길을갑니다.

웹 MVC는 응용 프로그램의 상태가있는 MVC 모델과는 상당히 다르기 때문에 매우 주관적이 될 수 있습니다. 웹 앱을 처리 할 때 주요 기능을 컨트롤러에서 유지하려고합니다. 나는 그들이 몇 가지 객체 나 모델을 인스턴스화하고, 취한 조치에 따라 몇 가지 방법을 실행하고, 뷰가 완료되면보기에 전달하기 위해 몇 가지 뷰 데이터를 수집하는 것을 좋아합니다. 더 단순할수록 더 좋을수록 핵심 비즈니스 로직을 모델에 넣었습니다.이 모델은 응용 프로그램 상태를 대표해야합니다.

도움이되기를 바랍니다.