Rails MVC의 책임과 의무를 알고 있습니다.

Rails MVC의 책임과 의무를 알고 있습니다.
왜 썼어요?
라일스의 책임과 의무를 이해하지 못하도록 방법을 어디에 써야 하는가?라는 생각, 어디서 그런 실현이 있었을까?집을 구하는 데 시간이 오래 걸렸다.이 글은 라일스 MVC의 책임과 의무를 이해하고 적합한 곳에 써서 실현하고 검색 속도를 높이기 위해 작성됐다.
하지 않는 일

단원의 깊이 발굴

계층 구조로 Rails 잡기
무엇이 차원 구조입니까?
간단하게 말하면 응용 프로그램을 책임과 의무에 부합되는 몇 가지 차원의 디자인 기법으로 간주하는 것이다.이 층 간의 교환에서 많은 경우 한 방향과 인접한 층과만 교환할 수 있는데 층상으로 변하기 때문에 차원 구조라고 부른다.
계층적 이점
어느 도면에서 무엇을 합니까?응용 프로그램의 발전에도 개발자는 설치된 구조를 쉽게 파악하고 유지보수성을 높일 수 있다는 정의다.또한 그룹 간 교환 방법을 결정하고 층상으로 제한하는 장점은 응용 프로그램에 변경이 있으면 그 영향 범위를 직접 참조층의 층으로 한정할 수 있다는 것이다.
Rails의 레이어 구조
Rails는 크게 4개의 레이어로 구성됩니다.
레이어
MVC
과업
프레젠테이션 레이어
View
사용자에게 정보를 표시하고 사용자의 입력을 설명합니다.HTML 또는 WebAPI인 경우
애플리케이션 계층
Controller
필드 층과 프레젠테이션 층의 교환을 진행하다.비즈니스 논리에 대한 지식은 없고 단지 업무를 조정할 뿐이다.
도메인 계층
Model
이른바 상업 논리를 표현하다.시스템으로 업무를 표현하는 모델과 처리를 설치했다.업무성의 유효성과 규칙의 적응 등.
인프라 계층
상부를 지탱하는 일반 기술.MySQL이나 Redis 같은 거.
상기 각 층의 관계성을 고려하여 다음과 같은 내용을 의식할 필요가 있다

Controller와 View를 통해 모델

을 호출하는 방법을 몰라야 합니다.

Controller는 View를 그리는 방법을 알지 말아야 합니다

도면층 규칙에 적용되는 것이 합리적입니까?
어떻게든 MVC를 레야르에 두고 생각해야 한다면 불합리한 상황이 발생할 수 있다.예를 들어 뷰에서 어떤 내용이 나올지 모르면 Conroller로 데이터를 준비해서 뷰에 전달할 수 없다.
즉, 엄밀히 말하면 MVC는 차원 구조에 적용될 수 없지만 사상적 준비로 그 안에 차원이 있는 것을 포착할 수 있다면 유지보수성이 높은 코드를 초래할 수 있다!내 생각에는 이렇다.
소형 컨트롤러의 대응 방법
층마다 책임과 의무를 나눠야 한다는 것을 깨달았지만, 눈앞의 문제를 해결할 책임과 의무를 잊고 모든 처리를 컨트롤러에 적어 작은 컨트롤러가 되기 쉽다.
내 컨트롤러를 그림으로 그리면 이런 느낌↓
모델 클래스는 데이터의 컨테이너(일반적으로 DB 모드와 기본적으로 일치)로 서비스 클래스가 존재하지 않으며 프로그램의 처리는 모두 Controller에 기록된 상태입니다.

질문

Controller가 비대해지고 코드 전망이 나빠진다

각 Controller에 유사한 코드가 분산되어 있음

의존 관계가 증가하여 유지 보수가 어렵다

의존 관계를 늘리기 위해, 유지보수가 번거롭다↓


Controller에 비즈니스 논리를 쓰지 마십시오.
펫 컨트롤러 상태에서는'커머셜 로직을 컨트롤러에 쓰지 말라'는 지적이 종종 나온다.네.
상업 논리는 무엇입니까?
조사를 하려면 비즈니스 논리로 다루면'시스템 핵심 부분','시스템 목적으로 다루는 곳'등의 설명을 자주 볼 수 있다.하지만 내 마음속의 해석은 이렇다.프레젠테이션(화면 그리기), 데이터 접근, 논리 세 가지 측면에서 응용 프로그램을 볼 때 프레젠테이션(화면 그리기)과 데이터 접근에 적용되지 않는 응용 프로그램은 논리적 비즈니스로 간주된다.
아는 거 있으면 알려주세요.🙇‍♂️
모호 모형 문제
나는 상술한 방법까지 채택하여 일단 통제자의 법이 도망갈 수 있게 하려고 한다.
하지만 다음은 작은 모형의 문제다.

작은 모형 자체가 문제가 아니다

작은 모형이 목표이고 작은 모형 자체가 문제가 아니다
문제

는 역층(모델)에 오지 말아야 하는 논리

를 포함한다.

모델에 써야 할 처리로 코드량이 많으면 문제가 아니다

작은 모형의 대응
다음은 대응 방침만 쓰고, 구체적인 실시 방안은 별도로 기재한다.
기능별 자르기

외부 파일을 통한 module화

서비스 클래스로 잘라내기

gm로 처리하다
패키지 이름
용도
ActiveDecorator
view에서 필요한 처리
CarrierWave
이미지 저장 방법 및 크기 변환
ActiveModelSerializers
json 형식으로 응답
감상
라일스의 MVC 각자의 책임과 임무 개요에 대한 이해와 보수성을 높이기 위한 각 층의 시행의 중요성을 이해함으로써 이전보다 MVC에 대한 이해가 깊어졌다고 생각한다.다만, 아직 개요를 잘 모르기 때문에 앞으로 구체적인 모호모형의 해결 방법을 실장 수준에서 이해하고 싶다.
참고 문장
이따가 추가할게요.