데이터 양식을 통해 레코드를 데이터베이스에 추가하는 간단한 MVC Java 애플리케이션을 만들었습니다.
내 앱은 데이터를 수집하고 유효성을 검사하고 저장합니다. 데이터가 다른 사용자로부터 온라인으로 제공되기 때문입니다. 데이터는 본질적으로 대부분 숫자입니다.
이제 데이터베이스 (SQL 서버)에 저장되는 숫자 데이터에서 내 앱이 계산을 수행하고 결과를 표시하기를 원합니다. 사용자는 계산이 수행되는 방식에 관심이 없으므로 캡슐화해야합니다. 사용자는 단순 계산 된 데이터 만 볼 수 있어야합니다 (예 : A 열 데이터에서 B 열 데이터를 C 열 데이터로 나눈 값). 동일한 저장 프로 시저를 작성하는 방법을 알고 있지만 3 계층 앱을 원합니다.
데이터베이스에 기록으로 저장하고 계산을 수행하여 작업 한 데이터를 원합니다. 원래 데이터는 영향을받지 않고 새 데이터 인 사후 계산은 데이터베이스에 새 엔터티 레코드로 저장되어야합니다.
이 배경 계산을위한 코드는 어디에 작성해야합니까? 규칙과 비즈니스 로직이므로 새 JavaBeans 파일에 넣어야합니까?
코멘트
- 데이터베이스로 작업하는 동안 OO 및 테스트 가능 상태 유지
- 비즈니스 로직은 모델에 대해 수행 / 운영하는 방법을 묻는 팀 / 부서의 사람에게 별명입니다. 이것이 ' 비즈니스 로직을 비즈니스 로직이라는 별도의 클래스에 저장할 수있는 이유입니다. UI 구성 요소의 형식을 지정하거나 표시하는 방법에 대한 질문에 대답하는 디자이너의 동의어 인 Presentation Logic에도 동일하게 적용됩니다. 프로그램 구성 요소를 함께 만들고 연결하는 방법에 대한 지식을 나타내는 개발자 논리 (직접 질문하고 대답하거나 동료에게 묻는 질문)도있을 수 있습니다.
답변
비즈니스 로직 은 모델 , 우리는 뚱뚱한 모델 과 날씬한 컨트롤러 .
시작점으로 컨트롤러 로직에서 시작해야합니다. 예 : 업데이트시 컨트롤러는 코드를 메소드 / 서비스 로 전달해야합니다. div id = “20b4911d25″>
모델에 대한 변경 사항을 제공합니다.
모델에서 쉽게 helper / 애플리케이션 비즈니스 규칙 또는 계산 을 검증 할 수있는 서비스 클래스입니다.
개념적 요약
-
컨트롤러는 애플리케이션 로직 용입니다. 애플리케이션이 속한 " 지식 영역 "과 상호 작용하려는 방식에 특정한 로직입니다.
-
모델은 애플리케이션과 독립적 인 로직 용입니다 . 이 로직은 해당 로직이 속한 " 지식 영역 "의 가능한 모든 애플리케이션에서 유효해야합니다.
-
따라서 모든 비즈니스 규칙을 모델에 배치하는 것이 논리적입니다.
댓글
- 명확하고 간결한 답변입니다 ..
- @Yusubov, 애플리케이션 로직과 비즈니스 로직의 차이점을 설명해 주시겠습니까?
- @Moh, 간단히 말해서 도움이되는 유행어입니다. 응용 프로그램의 기술 계층을 설명합니다. 비즈니스 로직은 기본적으로 기능 사양에 따른 시스템의 규칙입니다. 예를 들어 B 유형의 객체 A에는 C와 D가 있어야하지만 E는 아니어야합니다. Application Logic은 Java 서블릿 및 OJB를 사용하여 Oracle 데이터베이스에 유지하는 것과 같은 기술 사양에 가깝습니다.
- 원하십니까? 다음 단어에 대해 자세히 설명하세요.
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 ] - 올바른 것으로 이해했다면 언급 된 기사에서는 ' 애플리케이션 로직 '을 ' 비즈니스 로직 '. 따라서 비즈니스 로직을 참조하는 것은 컨트롤러 나 뷰에 배치해서는 안됩니다.
Answer
항상 그렇듯이 프로젝트의 복잡성에 따라 다릅니다.
도메인 모델 복잡성이 상대적으로 작은 사소한 응용 프로그램에서는 논리를 모델에 넣고 하루라고 할 수 있습니다.
그러나 복잡한 모델과 많은 비즈니스 규칙이있는 사소하지 않은 응용 프로그램의 경우 항목을 조금 더 분리하는 것이 좋습니다.
두 개 이상의 모델을 포함하는 비즈니스 논리를 넣으면 모델 간의 긴밀한 결합을 도입합니다.애플리케이션이 계속 성장함에 따라 이러한 모델은 너무 많이 알고있는 god models로 바뀌는 경향이 있습니다. 그리고 이것은 빠르게 테스트하고 유지하기 어려운 큰 혼란으로 바뀔 것입니다. 따라서이 경우 로직을 별도의 레이어에 배치하는 것이 좋습니다.
추상화를 결정할 때는 항상 앱의 복잡성과 목적을 고려하고 과도한 엔지니어링을 피하세요. 사소한 / 소규모 애플리케이션의 경우 필요한 것보다 많은 레이어를 도입하면 복잡성이 감소하는 대신 증가합니다.
Robert Martin (Uncle Bob)은 The Clean Architecture
에 대한 좋은 블로그 게시물을 가지고 있습니다.
- 이 질문은 MVC에만 해당됩니다. 비즈니스 로직은 항상 모델에 있어야합니다. 컨트롤러는 어댑터 일뿐입니다.
- MVC는 업계에서 가장 과부하가 걸린 용어 중 하나입니다. 저는 '이 용어가 책을 보증하므로이 용어의 기이함에 빠지고 싶지 않습니다. MVC를 사용한다고해서 ' 모델에 모든 논리를 넣어야한다는 의미는 아닙니다.
- 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이 얻은 것은 질문이 MVC에만 해당된다는 것입니다. MVC 관점과 MVC 관점에서만 시스템을 보는 데 동의하면 예, 모든 비즈니스 로직이 " 모델 ", 그러나 " 모델 "은 iv id =를 포함하여 여러 클래스 및 레이어를 포함 할 수 있습니다. “39dcde7ea6″>
유틸리티 클래스 " 및 " 서비스 레이어 " . 다시 말해, 서비스 레이어가 컨트롤러 또는 뷰의 일부라고 말하지 않습니다. ' 따라서 모델이 가장 적합합니다.
답변
비즈니스 로직을 모델에 넣는 것이 가장 좋은 방법으로 들릴 수 있습니다. 컨트롤러는 원격 웹 앱에서 호출을받습니다. MVC 웹 서비스의 컨트롤러는 호출을 받아 실행을 BL의 메서드로 리디렉션합니다. 이제 Business Logic은 “Model”에 포함될 수 있지만 “Business Logic”과 같은 다른 폴더에도 위치 할 수 있습니다. . 따라서 비즈니스 로직의 위치에 대한 엄격한 규칙이 없습니다.
저는 MVC 3.0을 기반으로 구축 된 웹 서비스를 사용해 왔으며 비즈니스 로직의 컨테이너는 다음과 같습니다. MVC 모델 .
댓글
- 동의합니다. 모델이 단순히 다른 비즈니스 로직 클래스에 의해 작동되는 데이터 구조 일 때 훨씬 더 유연한 애플리케이션을 얻을 수 있습니다. 간단한 예로, 속성을 사용한 유효성 검사에 대한 ASP.NET ' 접근 방식의 큰 실패라고 생각합니다. Person '의 FirstName 속성에 Required 속성에 주석을 달면 FirstName이 필요하지 않은 관리자보기를 만들면 어떻게됩니까? 비즈니스 로직 레이어는 모델을 사용하고 적절한 조치를 결정해야합니다.