MVC의 비즈니스 로직 [닫기]
답변:
비즈니스 규칙이 모델에 적용됩니다.
메일 링리스트에 대한 이메일을 표시한다고 가정하십시오. 사용자는 이메일 중 하나 옆에있는 "삭제"버튼을 클릭하고 컨트롤러는 모델에게 N 항목을 삭제하도록 알리고 모델이 변경된 뷰를 알립니다.
관리자의 이메일을 목록에서 제거해서는 안됩니다. 그것은 비즈니스 규칙이며 지식은 모델에 속합니다. 뷰는 결국 이 규칙을 어떻게 든 표현할 수 있습니다. 아마도 모델은 비즈니스 규칙의 기능인 "IsDeletable"특성을 노출하므로 특정 항목에 대해 뷰의 삭제 단추가 사용 불가능하지만 규칙 자체는 포함되지 않습니다. 보기에서.
이 모델은 궁극적으로 데이터의 게이트 키퍼입니다. UI를 전혀 터치하지 않고도 비즈니스 로직을 테스트 할 수 있어야합니다.
무엇보다도 주먹 :
MVC 패턴과 n- 계층 기반 설계 원칙을 혼용하고 있다고 생각합니다.
MVC 접근 방식을 사용한다고해서 애플리케이션을 계층화해서는 안된다는 의미는 아닙니다.
MVC가 프레젠테이션 계층의 확장과 같은 것으로 보이면 도움이 될 수 있습니다.
프리젠 테이션이 아닌 코드를 MVC 패턴에 넣으면 곧 복잡한 디자인이 될 수 있습니다.
따라서 비즈니스 로직을 별도의 비즈니스 계층에 넣는 것이 좋습니다.
: 그냥 이것 좀 봐 가지고 다 계층 아키텍처에 대한 Wikipedia 기사
그것은 말한다을 :
오늘날 MVC 및 이와 유사한 MVP (model-view-presenter)는 더 큰 시스템 의 프리젠 테이션 레이어 에만 적용되는 우려 디자인 패턴의 분리입니다 .
어쨌든 ... 엔터프라이즈 웹 애플리케이션 에 대해 이야기 할 때 UI에서 비즈니스 로직 계층으로의 호출은 (프레젠테이션) 컨트롤러 내부에 배치해야합니다.
컨트롤러가 실제로 특정 리소스에 대한 호출을 처리하고 비즈니스 로직을 호출하여 데이터를 쿼리하고 데이터 (모델)를 적절한보기에 연결하기 때문입니다.
Mud는 비즈니스 규칙이 모델에 적용된다고 말했습니다.
또한 사실이지만 (프레젠테이션) 모델 (MVC의 'M')과 티어 기반 애플리케이션 디자인의 데이터 계층 모델을 혼합했습니다.
따라서 데이터베이스 관련 비즈니스 규칙 을 애플리케이션의 모델 (데이터 계층)에 배치하는 것이 유효 합니다.
그러나 특정 UI에만 적용되므로 MVC 구조 프레젠테이션 레이어의 모델에 배치해서는 안됩니다.
이 기술은 도메인 기반 디자인을 사용하는지 아니면 트랜잭션 스크립트 기반 접근 방식을 사용하는지와 무관합니다.
내가 당신을 위해 그것을 시각화하자 :
프리젠 테이션 레이어 : 모델-보기-컨트롤러
비즈니스 계층 : 도메인 로직-애플리케이션 로직
데이터 계층 : 데이터 저장소-데이터 액세스 계층
위에서 본 모델은 MVC, DDD 및 데이터베이스 독립 데이터 계층을 사용하는 응용 프로그램이 있음을 의미합니다.
이것은 더 큰 엔터프라이즈 웹 응용 프로그램을 설계하는 일반적인 방법입니다.
그러나 간단한 비 DDD 비즈니스 계층 (도메인 논리가없는 비즈니스 계층)과 특정 데이터베이스에 직접 쓰는 간단한 데이터 계층을 사용하도록 축소 할 수도 있습니다.
권장하지는 않지만 전체 데이터 계층을 삭제하고 비즈니스 계층에서 직접 데이터베이스에 액세스 할 수도 있습니다.
그게 속임수입니다 ...이 도움이되기를 바랍니다 ...
[참고 :] 또한 현재 응용 프로그램에 둘 이상의 "모델"이 있다는 사실을 알고 있어야합니다. 일반적으로 응용 프로그램의 각 계층에는 자체 모델이 있습니다. 프리젠 테이션 레이어의 모델은보기에 따라 다르지만 종종 사용 된 컨트롤과 무관합니다. 비즈니스 계층에는 "도메인 모델"이라는 모델이있을 수도 있습니다. 일반적으로 도메인 기반 접근 방식을 선택하기로 결정한 경우입니다. 이 "도메인 모델"에는 데이터와 비즈니스 로직 (프로그램의 주요 로직)이 포함되며 일반적으로 프리젠 테이션 레이어와 무관합니다. 프레젠테이션 계층은 일반적으로 특정 "이벤트"(버튼 누름 등)에서 비즈니스 계층을 호출하여 데이터 계층에서 데이터를 읽거나 데이터 계층에 데이터를 씁니다. 데이터 계층에는 일반적으로 데이터베이스와 관련된 자체 모델이있을 수 있습니다.
문제는 이것이 어떻게 MVC 개념에 적합합니까?
답변-> 그렇지 않습니다!
글쎄-그것은하지만 완전히하지는 않습니다.
MVC는 1970 년대 말에 Smalltalk-80 프로그래밍 언어를 위해 개발 된 접근 방식이기 때문입니다. 그 당시 GUI와 개인용 컴퓨터는 흔하지 않았으며 월드 와이드 웹도 발명되지 않았습니다! 오늘날의 프로그래밍 언어와 IDE는 대부분 1990 년대에 개발되었습니다. 당시 컴퓨터와 사용자 인터페이스는 1970 년대와 완전히 다릅니다.
MVC에 대해 이야기 할 때이 점을 명심해야합니다.
Martin Fowler는 MVC, MVP 및 오늘날의 GUI에 대해 매우 유용한 기사를 작성했습니다.
비즈니스 로직이라는 용어는 제 생각에는 정확한 정의가 아닙니다. Evans는 자신의 저서 인 Domain Driven Design에서 두 가지 유형의 비즈니스 로직에 대해 이야기합니다.
- 도메인 로직.
- 응용 프로그램 논리.
이 분리는 제 생각에 훨씬 명확합니다. 그리고 다른 유형의 비즈니스 규칙이 있다는 것을 깨닫게되면 반드시 같은 장소로 갈 필요는 없다는 사실도 깨닫게됩니다.
도메인 로직은 실제 도메인에 해당하는 로직입니다. 따라서 회계 응용 프로그램을 만드는 경우 도메인 규칙은 계정, 전기, 세금 등에 관한 규칙이됩니다. 민첩한 소프트웨어 계획 도구에서 규칙은 백 로그의 속도 및 스토리 포인트를 기반으로 릴리스 날짜를 계산하는 것과 같습니다. 기타
이 두 가지 유형의 응용 프로그램 모두 CSV 가져 오기 / 내보내기가 관련이있을 수 있지만 CSV 가져 오기 / 내보내기 규칙은 실제 도메인과 관련이 없습니다. 이러한 종류의 논리는 응용 프로그램 논리입니다.
도메인 로직은 가장 확실하게 모델 계층으로 들어갑니다. 이 모델은 DDD의 도메인 계층에도 해당합니다.
그러나 애플리케이션 로직을 반드시 모델 계층에 배치 할 필요는 없습니다. 컨트롤러에 직접 배치하거나 해당 규칙을 호스팅하는 별도의 응용 프로그램 계층을 만들 수 있습니다. 이 경우 가장 논리적 인 것은 실제 응용 프로그램에 따라 다릅니다.
A1 : 비즈니스 로직이 Model참여 MVC합니다. 의 역할은 Model데이터 및 비즈니스 로직을 포함하는 것입니다. Controller반면에 사용자 입력을 받고 수행 할 작업을 결정해야합니다.
A2 : A Business Rule는의 일부입니다 Business Logic. 그들은 has a관계가 있습니다. Business Logic있다 Business Rules.
살펴보십시오 Wikipedia entry for MVC. MVC패턴 의 흐름을 언급하는 개요로 이동하십시오 .
또한보십시오 Wikipedia entry for Business Logic. 및 Business Logic로 구성 되는 것으로 언급된다 .Business RulesWorkflow
몇 가지 답변이 지적했듯이 멀티 티어 대 MVC 아키텍처에 대한 오해가 있다고 생각합니다.
멀티 티어 아키텍처는 애플리케이션을 계층 / 계층 (예 : 프리젠 테이션, 비즈니스 로직, 데이터 액세스)으로 분할합니다.
MVC는 응용 프로그램의 프레젠테이션 계층을위한 아키텍처 스타일입니다. 사소한 응용 프로그램의 경우 비즈니스 논리 / 비즈니스 규칙 / 데이터 액세스를 모델, 뷰 또는 컨트롤러에 직접 배치해서는 안됩니다. 그렇게하려면 프레젠테이션 계층에 비즈니스 로직을 배치하여 코드의 재사용 및 유지 관리 성을 줄입니다.
이 모델은 비즈니스 논리를 배치하기에 매우 합리적인 선택이지만,보다 나은 / 유지 관리가 용이 한 방법은 프레젠테이션 계층을 비즈니스 논리 계층과 분리하고 비즈니스 논리 계층을 만들고 필요할 때 모델에서 비즈니스 논리 계층을 호출하는 것입니다. 비즈니스 로직 계층은 차례로 데이터 액세스 계층을 호출합니다.
특히 응용 프로그램이 여러 계층을 사용하여 설계되지 않은 경우 MVC 구성 요소 중 하나에서 비즈니스 논리와 데이터 액세스를 혼합하는 코드를 찾는 것은 드문 일이 아닙니다. 그러나 대부분의 엔터프라이즈 응용 프로그램에서는 일반적으로 프레젠테이션 계층 내에 MVC 아키텍처가있는 다중 계층 아키텍처를 찾을 수 있습니다.
이것은 답변 된 질문이지만 "1 센트"를 드리겠습니다.
비즈니스 규칙은 모델에 속합니다. "모델"은 항상 (논리적으로 또는 물리적으로 분리 된) 다음으로 구성됩니다.
- 프레젠테이션 모델 -보기에 사용하기에 적합한 클래스 세트 (특정 UI / 프레젠테이션에 맞게 조정 됨)
- 도메인 모델 - 모델 의 UI 독립적 부분
- repository- "모델"의 스토리지 인식 부분.
비즈니스 규칙은 도메인 모델에 존재하며 프리젠 테이션에 적합한 형식으로 "프레젠테이션"모델에 노출되며 때로는 "데이터 계층"에 복제 (또는 시행)됩니다.
비즈니스 계층을 MVC 프로젝트의 모델에 배치하는 것은 의미가 없습니다.
상사가 프레젠테이션 레이어를 다른 것으로 변경하기로 결정했다고 말하면, 당신은 망하게 될 것입니다! 비즈니스 계층은 별도의 어셈블리 여야합니다. 모델에는 표시 할보기로 전달되는 비즈니스 계층의 데이터가 포함됩니다. 그런 다음 게시 후 모델은 비즈니스 계층에 상주하는 Person 클래스에 바인딩하고 PersonBusiness.SavePerson (p); 여기서 p는 Person 클래스입니다. 다음은 내가하는 일입니다 (BusinessError 클래스가 누락되었지만 BusinessLayer에도 적용됨).
Q1 :
비즈니스 로직은 두 가지 범주로 고려할 수 있습니다.
전자 메일 주소 제어 (고유성, 제약 조건 등), 송장에 대한 제품 가격 획득 또는 제품 객체를 기준으로 shoppingCart의 총 가격 계산과 같은 도메인 논리
학생 등록 프로세스 제어와 같이 비즈니스 프로세스라고하는보다 광범위하고 복잡한 워크 플로우
첫번째 범주에 들어가는 모델 및 두 번째 하나에 속하는 컨트롤러 . 두 번째 범주의 사례는 광범위한 응용 프로그램 논리이고 모델에 적용하면 모델의 추상화가 혼합 될 수 있기 때문입니다 (예를 들어, 이러한 결정을 한 모델 클래스 또는 다른 클래스로 분류해야하는지 여부는 명확하지 않습니다) 둘 다!).
모델과 컨트롤러의 특정 차이점에 대한 이 답변 을 참조하십시오.이 링크 는 매우 정확한 정의 와이 링크 는 멋진 Android 예제입니다.
요점은 위의 "Mud"와 "Frank"에 언급 된 메모는 "Pete"뿐만 아니라 사실 일 수도 있다는 것입니다 (비즈니스 로직은 비즈니스 로직의 유형에 따라 모델이나 컨트롤러에 넣을 수 있습니다).
마지막으로 MVC는 상황에 따라 다릅니다. 예를 들어, Android 애플리케이션에서는 웹 기반과 다른 일부 대체 정의가 제안됩니다 ( 예를 들어이 게시물 참조 ).
Q2 :
비즈니스 로직은보다 일반적이며 위에서 언급 한 "비 사이클론"과 같이 다음과 같은 관계가 있습니다.
비즈니스 규칙 ⊂ 비즈니스 로직
CRUD 데이터베이스 조작을위한 모델 = 코드.
Controller = 사용자 조치에 응답하고 조직 고유의 비즈니스 규칙에 따라 데이터 검색 또는 삭제 / 업데이트에 대한 사용자 요청을 모델로 전달합니다. 이러한 비즈니스 규칙은 도우미 클래스에서 구현되거나 너무 복잡하지 않은 경우 컨트롤러 작업에서 직접 구현할 수 있습니다. 컨트롤러는 최종적으로 새로운 디스플레이 또는 'updated, thanks'등과 같은 메시지 형태로 사용자에게 피드백을 제공하기 위해 뷰 자체를 업데이트하도록 요청합니다.
보기 = 모델의 쿼리를 기반으로 생성 된 UI입니다.
비즈니스 규칙이 어디로 가야하는지에 대한 어렵고 빠른 규칙은 없습니다. 어떤 디자인에서는 모델로 들어가고 다른 디자인에서는 컨트롤러에 포함됩니다. 그러나 컨트롤러와 함께 유지하는 것이 좋습니다. 모델이 데이터베이스 연결에 대해서만 걱정하도록하십시오.