뚱뚱한 모델과 마른 컨트롤러는 신 모델을 만드는 것처럼 들립니다.

뚱뚱한 모델과 마른 컨트롤러는 신 모델을 만드는 것처럼 들립니다.

---

나는 뚱뚱한 모델과 마른 컨트롤러 접근 방식 을 옹호하는 많은 블로그를 읽고 있습니다. 레일스 캠프. 결과적으로 라우터는 기본적으로 어떤 컨트롤러에서 어떤 메서드를 호출해야하는지 파악하고 있으며 모든 컨트롤러 메서드는 모델에서 해당 메서드를 호출 한 다음 뷰를 가져 오는 것입니다. 그래서 여기에 내가 이해하지 못하는 두 가지 우려가 있습니다.

1. 컨트롤러와 라우터는 경로를 기반으로하는 신과 같은 모델에서 메서드를 호출하는 것 외에는 다른 작업을 수행하지 않습니다.
2. 모델이 너무 많은 일을하고 있습니다. 이메일 보내기, 관계 생성, 다른 모델 삭제 및 수정, 작업 대기열 등. 기본적으로 이제 모델링 및 데이터 처리와 관련이있을 수도 있고 아닐 수도있는 모든 작업을 수행해야하는 신과 같은 개체가 있습니다.

어디에서 선을 그리나요? 이것은 단지 신의 패턴에 빠지지 않습니까?

---

_{Rails를 MVC 디자인 패턴의 핵심으로 보는 것은 최선의 생각이 아닐 수도 있습니다. 이 프레임 워크는 몇 가지 내재 된 결점으로 만들어졌고 ( 다른 게시물 에서 좀 더 자세히 설명했습니다 ) 커뮤니티는 이제 막 낙진 문제를 해결하기 시작했습니다. DataMapper2 개발 을 첫 번째 주요 단계로 볼 수 있습니다.}

일부 이론

그러한 조언을하는 사람들은 아주 흔한 오해에 시달리는 것 같습니다. 그럼 정리부터 시작하겠습니다. 현대 MVC 디자인 패턴에서 모델은 클래스 나 객체가 아닙니다. 모델은 레이어입니다.

MVC 패턴의 핵심 아이디어 는 우려 사항 분리이며 첫 번째 단계는 프리젠 테이션 레이어와 모델 레이어를 나누는 것입니다. 프레젠테이션 계층이 컨트롤러 (사용자 입력을 처리하는 인스턴스), 뷰 (인스턴스, UI 논리를 담당) 및 템플릿 / 레이아웃으로 나뉘는 것처럼 모델 계층도 마찬가지입니다.

모델 계층이 구성하는 주요 부분은 다음과 같습니다.

• 도메인 개체

  도메인 엔터티, 비즈니스 개체 또는 모델 개체라고도합니다 (혼란을 더하기 때문에 후자의 이름이 마음에 들지 않습니다). 이러한 구조는 사람들이 일반적으로 "모델"이라고 잘못 부르는 것입니다. 비즈니스 규칙 (특정 도메인 논리 단위에 대한 모든 수학 및 유효성 검사)을 포함하는 역할을합니다.

• 스토리지 추상화 :

  일반적으로 데이터 매퍼 패턴을 사용하여 구현됩니다 ( 이 이름을 남용한 ORM 과 혼동하지 마십시오 ). 이러한 인스턴스는 일반적으로 도메인 개체에서 정보 저장 및 검색 작업을 수행합니다. 각 도메인 객체는 여러 형태의 스토리지 (DB, 캐시, 세션, 쿠키, / dev / null)가있는 것처럼 여러 매퍼를 가질 수 있습니다.

• 서비스:

  응용 프로그램 논리 (즉, 도메인 개체 간의 상호 작용 및 도메인 개체와 저장소 추상화 간의 상호 작용)를 담당하는 구조. 프레젠테이션 레이어가 모델 레이어와 상호 작용하는 "인터페이스"처럼 작동해야합니다. 이것은 일반적으로 Rails와 유사한 코드에서 컨트롤러에서 끝나는 것입니다.

이러한 그룹 사이의 공간에는 DAO , 작업 단위 및 저장소 와 같은 여러 구조가있을 수 있습니다 .

_{아 ... 그리고 우리가 (웹의 맥락에서) MVC 애플리케이션과 상호 작용 하는 사용자 에 대해 이야기 할 때 그것은 인간이 아닙니다. "사용자"는 실제로 웹 브라우저입니다.}

그렇다면 신은 어떻습니까?

무섭고 모 놀리 식 모델을 사용하는 대신 컨트롤러는 서비스와 상호 작용해야합니다. 사용자 입력에서 특정 서비스 (예 : MailService또는 RecognitionService)로 데이터를 전달합니다 . 이런 식으로 컨트롤러는 모델 계층의 상태를 변경하지만 명확한 API를 사용하고 내부 구조를 엉망으로 만들지 않고 수행됩니다 (누수 추상화를 유발할 수 있음).

이러한 변경은 즉각적인 반응을 일으키거나 뷰 인스턴스가 모델 계층에서 요청하는 데이터에만 영향을 미치거나 둘 다에 영향을 미칠 수 있습니다.

각 서비스는 여러 도메인 개체 및 저장소 추상화와 상호 작용할 수 있습니다 (일반적으로 소수에 불과 함). 예를 들어, RecogitionService기사에 대한 스토리지 추상화에 대해 덜 신경 쓸 수 없습니다.

마무리 노트

이렇게하면 모든 수준에서 단위 테스트가 가능하고 결합이 낮고 (올바르게 구현 된 경우) 명확하게 이해할 수있는 아키텍처를 가진 애플리케이션을 얻을 수 있습니다.

하지만 MVC는 소규모 애플리케이션을위한 것이 아닙니다. MVC 패턴을 사용하여 방명록 페이지를 작성하는 경우 잘못하고있는 것입니다. 이 패턴은 대규모 응용 프로그램에서 법과 질서 를 집행하기위한 것 입니다.

_{PHP를 기본 언어로 사용하는 사람들 에게이 게시물 은 관련성 이 있을 수 있습니다. 코드 조각 몇 개로 모델 계층에 대한 좀 더 긴 설명입니다.}

---

"모델"클래스가 제대로 구현되지 않으면 예, 귀하의 우려는 관련이 있습니다. 모델 클래스는 이메일 (인프라 작업)을 수행해서는 안됩니다.

The real question is what does model in MVC imply. It isnt restricted to POCO classes with a few methods. Model in MVC means Data and Business logic. Treat it as a superset of classic core POCO models.

View ==== Controller ==== Model ---> Business Process layer --> Core models

Throw in Infrastructure assemblies and Data Access layers and use injection to hand that into the BPL then your a process is using MVC as intended.

BPL may invoke UoW / Respository patterns, and execute business rules and call Infrastructure features by way of injected Objects or interface patters.

So the recommendation to keep a controller skinny doesnt mean the "person" class in a classic Core model should have 50 methods, and call Email directly. You are right to think this is wrong.

The Controller May still be required to instantiate and inject Infrastructure classes into the BPL or core layer if called directly. There should be a business layer or at least classes orchestrating calls across Classic Object model classes. Well thats my "view" anyway ;-)

For generic take on MVC the wiki description http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller

A Little Blog that talks about the "M" in MVC. http://www.thedeveloperday.com/skinny-controllers/

---

I think you can make a distinction between a single fat model (possibly named App or Application), and several fat models broken down into logical groups (Business, Customer, Order, Message). The latter is how I structure my apps, and each model roughly corresponds to a database table in a relational database or collection in a document database. These models handle all aspects of creating, updating, and manipulating the data that makes up the model, whether it is talking to the database or calling an API. The controller is very thinm responsible for little mor that calling the appropriate model and selecting a template.

참고URL : https://stackoverflow.com/questions/14044681/fat-models-and-skinny-controllers-sounds-like-creating-god-models