나는 뚱뚱한 모델과 마른 컨트롤러 접근 방식 을 옹호하는 많은 블로그를 읽고 있습니다. 레일스 캠프. 결과적으로 라우터는 기본적으로 어떤 컨트롤러에서 어떤 메서드를 호출할지 알아 내고 컨트롤러 메서드는 모델에서 해당 메서드를 호출 한 다음 뷰를 가져 오는 것입니다. 그래서 여기에 내가 이해하지 못하는 두 가지 우려가 있습니다.
어디에 선을 그리나요? 이것은 단지 신의 패턴에 빠지지 않습니까?
답변:
Rails를 MVC 디자인 패턴의 필수 요소로 보는 것은 최선의 생각이 아닐 수 있습니다. 프레임 워크는 몇 가지 내재 된 결점으로 만들어졌고 ( 다른 게시물 에서 좀 더 자세히 설명했습니다 ) 커뮤니티는 이제 막 낙진을 해결하기 시작했습니다. DataMapper2 개발 을 첫 번째 주요 단계로 볼 수 있습니다.
그러한 조언을하는 사람들은 아주 흔한 오해에 시달리는 것 같습니다. 그럼 정리부터 시작하겠습니다. 현대 MVC 디자인 패턴에서 모델은 클래스 나 객체가 아닙니다. 모델은 레이어입니다.
MVC 패턴의 핵심 아이디어 는 우려 사항 분리이며 첫 번째 단계는 프리젠 테이션 레이어와 모델 레이어를 나누는 것입니다. 프레젠테이션 계층이 컨트롤러 (사용자 입력을 처리하는 인스턴스), 뷰 (인스턴스, UI 논리를 담당) 및 템플릿 / 레이아웃으로 나뉘는 것처럼 모델 계층도 마찬가지입니다.
모델 계층이 구성하는 주요 부분은 다음과 같습니다.
도메인 엔터티, 비즈니스 개체 또는 모델 개체라고도합니다 (혼란을 더하기 때문에 후자의 이름이 마음에 들지 않습니다). 이러한 구조는 사람들이 일반적으로 "모델"이라고 잘못 부르는 것입니다. 그들은 비즈니스 규칙 (특정 도메인 논리 단위에 대한 모든 수학 및 유효성 검사)을 포함합니다.
스토리지 추상화 :
일반적으로 데이터 매퍼 패턴을 사용하여 구현됩니다 ( 이 이름을 남용한 ORM 과 혼동하지 마십시오 ). 이러한 인스턴스는 일반적으로 도메인 개체에서 정보 저장 및 검색 작업을 수행합니다. 각 도메인 객체는 여러 형태의 스토리지 (DB, 캐시, 세션, 쿠키, / dev / null)가있는 것처럼 여러 매퍼를 가질 수 있습니다.
서비스:
응용 프로그램 논리 (즉, 도메인 개체 간의 상호 작용 및 도메인 개체와 스토리지 추상화 간의 상호 작용)를 담당하는 구조. 프레젠테이션 레이어가 모델 레이어와 상호 작용하는 "인터페이스"처럼 작동해야합니다. 이것은 일반적으로 Rails와 유사한 코드에서 컨트롤러에서 끝나는 것입니다.
이러한 그룹 사이의 공간에는 DAO , 작업 단위 및 저장소 와 같은 여러 구조가있을 수 있습니다 .
아 ... 그리고 우리가 (웹의 맥락에서) MVC 애플리케이션과 상호 작용 하는 사용자 에 대해 이야기 할 때 그것은 인간이 아닙니다. "사용자"는 실제로 웹 브라우저입니다.
무섭고 모 놀리 식 모델을 사용하는 대신 컨트롤러는 서비스와 상호 작용해야합니다. 사용자 입력에서 특정 서비스 (예 : MailService또는 RecognitionService)로 데이터를 전달합니다 . 이런 식으로 컨트롤러는 모델 계층의 상태를 변경하지만 명확한 API를 사용하고 내부 구조를 엉망으로 만들지 않고 수행됩니다 (누수 추상화를 유발할 수 있음).
이러한 변경은 즉각적인 반응을 일으키거나 뷰 인스턴스가 모델 계층에서 요청하는 데이터에만 영향을 미치거나 둘 다에 영향을 미칠 수 있습니다.
각 서비스는 여러 도메인 개체 및 저장소 추상화와 상호 작용할 수 있습니다 (일반적으로 소수에 불과하지만). 예를 들어, RecogitionService기사에 대한 스토리지 추상화에 대해 덜 신경 쓸 수 없습니다.
이렇게하면 모든 수준에서 단위 테스트가 가능하고 결합이 낮고 (올바르게 구현 된 경우) 명확하게 이해할 수있는 아키텍처를 가진 애플리케이션을 얻을 수 있습니다.
하지만 MVC는 소규모 애플리케이션을위한 것이 아닙니다. MVC 패턴을 사용하여 방명록 페이지를 작성하는 경우 잘못하고있는 것입니다. 이 패턴은 대규모 응용 프로그램에서 법과 질서 를 시행하기위한 것 입니다.
PHP를 기본 언어로 사용하는 사람들 에게이 게시물 은 관련성 이 있을 수 있습니다. 코드 조각 몇 개로 모델 계층에 대한 좀 더 긴 설명입니다.
"모델"클래스가 제대로 구현되지 않으면 예, 귀하의 우려는 관련이 있습니다. 모델 클래스는 이메일 (인프라 작업)을 수행해서는 안됩니다.
진짜 질문은 MVC의 모델이 의미하는 바입니다. 몇 가지 방법이있는 POCO 클래스로 제한되지 않습니다. MVC의 모델은 데이터 및 비즈니스 로직을 의미합니다. 클래식 핵심 POCO 모델의 상위 세트로 취급하십시오.
보기 ==== 컨트롤러 ==== 모델 ---> 비즈니스 프로세스 계층-> 핵심 모델
인프라 어셈블리 및 데이터 액세스 레이어를 넣고 주입을 사용하여 BPL에 전달하면 프로세스가 의도 한대로 MVC를 사용합니다.
BPL은 UoW / Respository 패턴을 호출하고 삽입 된 객체 또는 인터페이스 패턴을 통해 비즈니스 규칙을 실행하고 인프라 기능을 호출 할 수 있습니다.
따라서 컨트롤러를 얇게 유지하라는 권장 사항은 클래식 Core 모델의 "person"클래스에 50 개의 메서드가 있어야하며 Email을 직접 호출해야 함을 의미하지는 않습니다. 이것이 틀렸다고 생각하는 것이 옳습니다.
컨트롤러는 직접 호출되는 경우 인프라 클래스를 인스턴스화하고 BPL 또는 코어 계층에 삽입하는 데 여전히 필요할 수 있습니다. 클래식 개체 모델 클래스에서 호출을 조정하는 비즈니스 계층 또는 최소한 클래스가 있어야합니다. 어쨌든 내 "보기"입니다 ;-)
MVC에 대한 일반적인 내용은 위키 설명 http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller
MVC의 "M"에 대해 이야기하는 작은 블로그. http://www.thedeveloperday.com/skinny-controllers/