컨트롤러 계층에 얼마나 많은 비즈니스 로직이 있어야합니까?

때로는 애플리케이션의 컨트롤러 코드에 일부 비즈니스 로직이 표시됩니다. 이것은 일반적으로 모델에서 호출 할 메소드 및 / 또는 전달할 인수를 구별하는 논리입니다.

이것의 또 다른 예는 일련의 비즈니스 규칙에 따라 모델에서 리턴 된 데이터를 형식화하거나 삭제하는 컨트롤러에 존재하는 유틸리티 기능 세트입니다.

이것은 효과가 있지만 재난으로 유혹되는지 궁금합니다. 컨트롤러와 모델간에 공유되는 비즈니스 로직이있는 경우 두 계층을 더 이상 분리 할 수 ​​없으며 비즈니스 로직 관련 코드의 위치에서 이러한 불균일성으로 인해 코드를 상속받는 사람이 혼동 될 수 있습니다.

내 질문은 컨트롤러에서 얼마나 많은 비즈니스 로직을 허용해야하며 어떤 상황에서 어떤 상황에서 허용되어야합니까?

이상적으로는 없음

그러나 항상 가능하지는 않습니다. 나는 20 % 또는 10 줄과 같은 어려운 숫자를 줄 수 없으며, 대답 할 수없는 지점에 따라 다릅니다. 디자인 패턴과 상황을 약간 구부려 야하는 상황을 사용하는 방법을 설명 할 수 있습니다.

내 마음에 그것은 전적으로 응용 프로그램의 목적에 달려 있습니다. 게시 할 간단한 REST API를 작성 하시겠습니까? 깨끗하게 분리하거나 패턴을 잊어 버리십시오. 한 시간 안에 작동하는 버전을 만들 수 있습니다. 더 큰 건물을 만드시겠습니까? 아마도 최선을 다할 것입니다.

개별적으로 포함 된 시스템을 구축하는 것이 목표입니다. 두 시스템이 상호 작용하는 방식에 특정한 비즈니스 논리를 작성하기 시작하면 문제가됩니다. 더 자세히 보지 않으면 의견을 줄 수 없습니다.

디자인 패턴은 주형이며 잘 작성된 코드를 기반으로 엄격하게 준수하는 금형입니다. 패턴을 엄격하게 준수하면 코드가 잘못 되지는 않지만 시간이 더 걸리고 더 많은 코드 를 작성할 수 있습니다 .

디자인 패턴은 유연하며 필요 에 맞게 조정 하십시오 . 그들을 너무 많이 구부리면 깨집니다. 필요한 것을 알고 가장 가까운 디자인 패턴을 선택하십시오.

가능한 적게. 바람직하게는 없다.

컨트롤러는 요청을 수락하고 요청을 처리하기 위해 올바른 도메인 서비스를 요청하고 올바른보기로 응답을 전달하는 것과 관련이 있어야합니다.

이 프로세스에서 모든 "비즈니스 로직"은 도메인 서비스에 존재해야합니다.

도메인 객체를 가져 와서 뷰 모델을 생성하는 기능이있는 경우 컨트롤러와 공존 할 수 있습니다. 그러나 해당 뷰를 위해서만 존재하는 코드 여야합니다 . 데이터 삭제에 대한 비즈니스 수준 규칙이있는 경우 해당 단위 테스트와 함께 도메인 / 서비스 수준에 존재해야합니다.

"비즈니스 로직"이라는 용어는 사람들이 이것이 의미하는 바에 대해 다른 의견을 가지고 있기 때문에 종종 혼동되는 것입니다. 제 생각에 "비즈니스 로직"이라는 용어는 두 가지 영역을 다룹니다.

• 도메인 로직
• 응용 로직

Domain Logic은 비즈니스와 관련된 핵심 영역과 관련된 논리이므로 회계사를위한 응용 프로그램을 작성하는 경우 세금 규칙, 장부 유지 규칙 등이 도메인 논리의 일부입니다.

응용 프로그램 논리는 컴퓨터 프로그램을 실행하고 있다는 사실과 관련된 논리입니다. 이것은 CSV 가져 오기 내보내기, 마법사 등과 같은 항목 일 수 있습니다. 잊어 버린 비밀번호 이메일 작성과 같은 항목이 포함될 수도 있습니다.

컨트롤러 계층에 배치 할 수있는 "비즈니스 로직"의 종류는 응용 프로그램 로직입니다. 어쩌면 모든 응용 프로그램 논리가 해당되는 것은 아닙니다. 그러나 도메인 계층을 컨트롤러 계층에 배치해서는 안됩니다. 그것은 분명히 도메인 레이어에 있어야합니다.

데이터를 형식화하거나 삭제하는 논리에 대해 이야기했습니다. 서식은 반드시 응용 프로그램 논리 여야합니다. 반면에 데이터를 삭제하는 것이 도메인 규칙을 기반으로하는 경우 삭제는 도메인 논리 일 수 있습니다. 상황에 따라 다릅니다.

컨트롤러는 도메인 로직에 매우 적합해야합니다.

컨트롤러는 추상 서비스 / 리포지토리 계층을 통해 데이터 저장소에서 레코드를 검색하고 동일한 (또는 관련) 서비스를 통해 데이터를 데이터 저장소로 다시 전달하는 등의 작업을 위임해야합니다. 이러한 작업 사이의 역학 및 미세 작업은 일반적으로 컨트롤러 이외의 위치에 속합니다.

저의 컨트롤러에 작은 데이터 위생 방법을 추가하여 저장소에 데이터를 다시 저장하는 경우가 종종 있습니다. 효과적인 솔루션이지만 컨트롤러의 의도 된 역할과 잘 맞지 않습니다. 이상적으로, 모델을 수정, 검증 또는 파싱 할 모든 것은 모델 자체가 아닌 경우에 가깝게 발생해야합니다. 예를 들어, 저장하기 전에 모델 객체를 '정리'해야하는 경우 모델에서 또는 모델 저장을 처리하는 서비스의 일부로 SanitizeInputs () 메서드를 사용하는 것이 좋습니다.

실용적인 관점에서, 당신은 좋은 패턴 호환 접근법이없는 것을 시도 할 때 컨트롤러의 로직 또는 모델의 컨트롤러 동작으로 끝납니다. 큰 인프라가없는 앱을 작성하는 경우에는 두 배가됩니다.

어느 쪽이든 갈 수 있지만 일반적으로 이상한 비트가 둘 이상의 컨트롤러 작업에 나타날 가능성이 있는지 생각하려고 시도합니다. 그것이 확실하지 않다면, 나는 그것이 다른 곳보다 한 곳에서 더 "맞는"것이라고 생각하려고합니다. 컨트롤러에서 벗어나기 위해 일반적으로 모델에 넣지 못함 (작은 컨트롤러와 더 강력한 데이터 객체, YMMV에 대한 개인 선호)

세 번째 옵션은 유틸리티 항목을 별도의 유틸리티 클래스로 참조하는 것이지만, 많은 사람들의 견해로는 패턴과 다소 반대입니다.

또한 패턴을 엄격하게 따르지 않기 때문에 반드시 재해로 유혹하지는 않습니다. 이 프로젝트에서 상당한 양의 코드를 재사용 할 것으로 예상하지 않는 한 프로젝트 자체에 일관성이 있다는 것에 대해 훨씬 더 걱정할 것입니다 (예 : 위치를 선택한 후이 비트를 넣는 위치에 플립 플롭하지 마십시오) 어떤 이유로 든 프로젝트 중간 부분을 저장하려고하는 다시 쓰기보다. 공통 패턴에서 벗어난 위치 및 이유를 문서 / 설명하고이 응용 프로그램의 예상 패턴을 정의하십시오.

MVC는 한 시점에서 기존 패턴 자체와의 편차였습니다.

프로그래밍의 다른 많은 흥미로운 개념과 마찬가지로 MVC는 특정 시나리오를 구현하기 위해 밀접하거나 유사한 전략 군에 구조와 초점을 가져 오는 강력한 패러다임입니다.

다른 많은 프로그래밍 개념과 마찬가지로 MVC는 현실을 단순화하고 작은 세부 사항을 버리고 따라야 할 조잡한 와이어 프레임 모델을 제공합니다. 현실의 다른 많은 단순화와 마찬가지로, 그것은 인간의 마음에서 볼 수 있듯이 혼란을 혼란에 빠뜨리는 일을 전혀하지 않습니다.

그러나 다른 많은 프로그래밍 개념과 마찬가지로 MVS는 현실을 단순화 한 것입니다. 완벽하지 않고 철저하지도 않습니다. 그렇기 때문에 실제 시나리오를 지나치게 단순화 된 모델에 맞추는 것이 불가능합니다. 그러므로 이것과 비슷한 많은 질문이 생깁니다.

• 컨트롤러에 얼마나 많은 로직이 들어가야합니까?

• 뷰에 조건부 논리가 포함되어야하는지 여부

• 비즈니스 엔터티에서 직접 찾을 수없는 추가 데이터가 모델에 포함되어야하는지 여부

이들은 모두 MVC의 개념 아이디어를 정확하고 완전하게 맞추기 위해 코드를 조정하려는 시도에서 나온 것입니다.

당신에게 내 대답은 시도하지 않습니다. MVC는 구조를 제공합니다. 이 기초를 중심으로 응용 프로그램을 작성하지만 완벽하게 맞지 않을 것으로 기대하십시오. 편차가있을 것입니다. 정상입니다. 그것들을 통제하기 위해 지켜보십시오.