MVC 설계에서 비즈니스 로직을 어디에 배치해야합니까?

데이터 형식을 통해 레코드를 데이터베이스에 추가하는 간단한 MVC Java 응용 프로그램을 만들었습니다.

내 앱은 데이터를 수집하고 데이터를 확인하고 저장합니다. 데이터가 다른 사용자로부터 온라인으로 제공되기 때문입니다. 데이터는 본질적으로 숫자입니다.

이제 데이터베이스 (SQL 서버)에 저장된 숫자 데이터에서 앱이 계산을 수행하고 결과를 표시하기를 원합니다. 사용자는 계산 방법에 관심이 없으므로 캡슐화해야합니다. 사용자는 단순 계산 데이터 만 볼 수 있어야합니다 (예 : A 열 데이터에서 B 열 데이터를 C 열 데이터로 나눈 값). 저장 프로 시저를 작성하는 방법을 알고 있지만 3 계층 앱을 원합니다.

데이터베이스에 레코드로 넣은 데이터를 계산하고 계산을 수행하기를 원했습니다. 원본 데이터는 영향을받지 않고 계산 후 새 데이터는 새 엔터티 레코드로 데이터베이스에 저장해야합니다.

이 백그라운드 계산을위한 코드를 어디에 작성해야합니까? 규칙 및 비즈니스 로직이므로 새 JavaBeans 파일에 넣어야합니까?

— BriskLabs 파키스탄
소스

데이터베이스로 작업하는 동안 OO 유지 및 테스트

— gnat

답변:

비즈니스 로직은 에 배치해야합니다 모델 , 우리는 지방을 목표로해야한다 모델 과 마른 체형의 컨트롤러 .

시작점으로 컨트롤러 로직에서 시작해야합니다. 예를 들어 : 업데이트시 , 컨트롤러는에 코드를 직접해야 방법 / 서비스 제공 모델에 변경 사항을.

이 모델에서는 응용 프로그램 비즈니스 규칙 또는 계산을 확인할 수있는 도우미 / 서비스 클래스를 쉽게 만들 수 있습니다.

개념적 요약

컨트롤러는 어플리케이션 로직 용입니다. 응용 프로그램이 자신이 속한 "지식 영역"과 상호 작용하려는 방식과 관련된 논리입니다.
모델은 응용 프로그램의 독립적 인 논리입니다 . 이 논리는 그것이 속한 "지식 영역"의 모든 가능한 응용에서 유효해야합니다.
따라서 모든 비즈니스 규칙을 모델에 배치하는 것이 논리적입니다.

— 엘 유수 보프
소스

명확하고 간결한 답변 ..

— hanzolo

@Yusubov, 애플리케이션 로직과 비즈니스 로직의 차이점을 설명해 주시겠습니까?

— Mohamad

@Moh, 간단히 말해서 이것은 응용 프로그램의 기술 계층을 설명하는 데 도움이되는 전문 용어입니다. 비즈니스 로직은 기본적으로 기능 사양에 따른 시스템 규칙입니다. 예를 들어, B 유형의 오브젝트 A는 C와 D를 의미하지만 E는 아니어야합니다. Application Logic은 Java 서블릿 및 OJB를 사용하여 Oracle 데이터베이스에 유지하는 것과 같은 기술 사양에 가깝습니다.

— EL Yusubov

당신은이 말에 정교한시겠습니까 :

The most common mistakes are to implement application logic operations inside the controller or the view(presentation) layer.

[ php-html.net/tutorials/model-view-controller-in-php을 ]

— 레보

내가 올바르게 이해했다면 언급 된 기사는 '응용 프로그램 논리'를 '비즈니스 논리'로 언급합니다. 따라서 비즈니스 로직을 나타내는 어떤 것도 컨트롤러 나 뷰에 배치해서는 안됩니다.

— EL Yusubov

항상 그렇듯이 프로젝트의 복잡성에 달려 있습니다.

도메인 모델 복잡도가 비교적 작은 사소한 응용 프로그램에서는 모델에 논리를 넣고 하루에 호출 할 수 있습니다.

그러나 복잡한 모델과 많은 비즈니스 규칙이있는 사소한 응용 프로그램의 경우 사물을 조금 더 분리하는 것이 좋습니다.

둘 이상의 모델과 관련된 비즈니스 논리를 모델에 넣으면 해당 모델간에 긴밀한 연결이 도입됩니다. 응용 프로그램이 계속 증가함에 따라 이러한 모델은 god models너무 많이 알고있는 경향이 있습니다. 그리고 이것은 테스트하고 유지하기 어려운 큰 혼란으로 빠르게 변할 것입니다. 따라서이 경우 논리를 별도의 계층에 배치하는 것이 좋습니다.

추상화를 결정할 때는 항상 앱의 복잡성과 목적을 고려하고 과도한 엔지니어링을 피하십시오. 사소한 응용 프로그램의 경우 필요한 것보다 많은 계층을 도입하면 계층을 줄이는 대신 복잡성이 증가합니다.

로버트 마틴 (Uncle Bob)은이 주제에 관한 좋은 블로그 게시물을 가지고 있습니다 : The Clean Architecture.

— 하칸 데릴
소스

질문은 MVC에만 해당됩니다. 비즈니스 로직은 항상 모델에 있어야합니다. 컨트롤러는 어댑터 일뿐입니다.

— jgauffin 5

MVC는 업계에서 가장 과부하 된 용어 중 하나입니다. 나는 책을 보증하기 때문에이 용어의 단점에 빠져 가고 싶지 않습니다. 단지 MVC를 사용한다고해서 모든 논리를 모델에 넣어야한다는 의미는 아닙니다.

— Hakan Deryal

Steve Burbeck (Smalltalk 팀)의 정의 :

The controller interprets the mouse and keyboard inputs from the user, commanding the model and/or the view to change as appropriate

. 어댑터 정의입니다.

— jgauffin

모델에 모든 논리를 넣으면 수천 줄의 유지 보수가 불가능한 혼란이 생길 수 있습니다. 거기에 있었다. 유틸리티 클래스와 서비스 계층을 갖는 것은 죄가 아닙니다.

— asthasr

jgauffin이 얻는 것은 MVC에 대한 질문입니다. 우리가 MVC 관점과 MVC 관점에서만 시스템을 보는 것에 동의한다면, 모든 비즈니스 로직은 "모델"에 속하지만 "모델"은 "유틸리티 클래스"를 포함한 여러 클래스와 계층을 포함 할 수 있습니다. "서비스 계층". 다시 말해서 서비스 계층이 컨트롤러 또는 뷰의 일부라고 말하지 않으므로 모델에 가장 적합합니다.

— DavidS

비즈니스 로직을 모델에 넣는 것이 가장 좋은 방법 일 수 있습니다. 컨트롤러가 원격 웹 앱으로부터 전화를받습니다. MVC 웹 서비스의 컨트롤러는 호출을 받아서 실행을 BL의 메소드로 경로 재 지정합니다. 이제 Business Logic을 'Model'에 포함 할 수 있지만 'Business Logic'과 같은 다른 폴더에 배치 할 수도 있습니다 . 따라서 비즈니스 로직의 위치에 대한 엄격한 규칙은 없습니다.

MVC 3.0을 기반으로 한 웹 서비스를 사용하고 있으며 비즈니스 로직 컨테이너는 MVC MODEL 입니다.

— 몬티 파이 튼
소스

동의한다. 모델이 단순히 다른 비즈니스 로직 클래스에 의해 수행되는 데이터 구조 인 경우 훨씬 유연한 응용 프로그램을 얻을 수 있습니다. 간단한 예로, 속성을 사용하여 유효성 검사에 대한 ASP.NET의 접근 방식이 크게 실패했다고 생각합니다. 필수 속성으로 개인의 FirstName 속성에 주석을 달면 FirstName이 필요하지 않은 관리자보기를 만들면 어떻게됩니까? 비즈니스 로직 계층은 모델을 사용하고 적절한 조치를 결정해야합니다.

— xr280xr