MVC 프레임 워크로서의 JSF 이해
MVC 프레임 워크로서의 JSF 이해
나는 JSF를 읽고 있는데 왜 JSF가 MVC 프레임 워크인지 (또는 적어도 어떤 부분이 어떤 "문자"에 속하는지) 혼란스러워합니다.
이 질문을 살펴 보았습니다. JSF MVC 프레임 워크에서 MVC는 어떤 구성 요소입니까?
집계 된 뷰에서 보지 않으면 모델은 엔티티이고 뷰는 XHTML 코드이고 컨트롤러는 관리 빈입니다. 흠 ... 좋아요.하지만 뷰는 예를 들어 엔티티 집합을 반환하는 추가 비즈니스 논리 호출을 수행하는 데 자주 의존하지 않습니다. 설명이 여전히 적합합니까?
내가 읽은 한 책은 그것을 관리 빈이라고 설명했다. Faces Servlet (컨트롤러)이 비즈니스 계층 (모델)을 호출하는 데 사용하는 일종의 "메시지"전달자이고 XHTML 코드는 뷰입니다.
설명과 차이점이 너무 많아서 무엇을 어떻게 이해해야하는지 모르겠습니다.
JSF 및 다른 많은 웹 프레임 워크에서 MVC의 어느 부분에 해당하는 부분이 있는지가 종종 완전히 명확하지 않은 이유 중 하나는 MVC 패턴이 원래 데스크톱 애플리케이션 용으로 고안 되었기 때문입니다.
데스크톱 애플리케이션에서 노드 M, V 및 C는 최대 연결 그래프이며, 이는 각 부분이 다른 모든 부분과 통신 할 수 있음을 의미합니다. 예를 들어 모델이 변경되면이 변경 사항을 뷰에 푸시 할 수 있습니다. 이는 데스크톱 애플리케이션에 뷰의 여러 표현이있는 경우 특히 볼 수 있습니다. 하나를 변경하고 다른 업데이트를 실시간으로 확인하십시오.
클라이언트 / 서버 및 웹 애플리케이션의 요청 / 응답 특성으로 인해 클래식 MVC는 대부분의 웹 프레임 워크에 1 : 1로 매핑되지 않습니다.
특히 JSF에서 매핑은 다음과 같습니다.
- 모델 -서비스 / DAO와 이들이 생산하고 소비하는 엔티티. 이에 대한 진입 점은 관리 빈이지만 JSF가 일부인 Java EE에서는 일반적으로 이러한 아티팩트가 각각 EJB 및 JPA에 의해 구현됩니다.
- 보기 -전체 페이지로 UI 구성 요소 및 구성. 이것은 완전히 JSF 도메인에
UIComponent있으며 각각 JSF 및 Facelet에 의해 구현됩니다 . - 컨트롤러 -사용자의 명령과 들어오는 데이터를 처리하는 교통 경찰은이를 올바른 부분으로 라우팅하고 표시 할보기를 선택합니다. JSF에서는이 컨트롤러를 작성하지 않지만 이미 프레임 워크에서 제공합니다 (
FacesServlet).
특히 마지막 부분은 잘 이해되지 않는 경우가 많습니다. JSF에서는 컨트롤러를 구현하지 않습니다. 결과적으로, 백업 빈이나 다른 종류의 관리 빈은 컨트롤러 가 아닙니다 .
첫 번째 부분 (모델)도 항상 명확하게 이해되는 것은 아닙니다. 비즈니스 로직은 EJB와 JPA에 의해 구현 될 수 있지만 JSF의 관점에서 보면 값 바인딩에서 참조하는 모든 것이 모델입니다. 여기에서 JSF 라이프 사이클 단계 중 하나의 이름이 Update Model. 이 단계에서 JSF는 UI 구성 요소의 데이터를 모델로 푸시합니다. 그런 의미에서 (JSF) 관리 빈이 모델입니다.
JSF 자체가 개념을 명시 적으로 정의하지는 않지만, backing bean 이라고하는 관리 빈의 반복적이고 특정한 사용이 자주 있습니다.
JSF의 경우 backing bean은 여전히 모델이지만 실제로는 Model, View 및 Controller의 중간에있는 배관 요소입니다. 일부 컨트롤러 작업으로 보일 수있는 일부 작업을 수행하기 때문에 이것은 종종 컨트롤러로 오인됩니다. 그러나 이전에 설명했듯이 이것은 정확하지 않습니다. 또한 일부 모델 작업을 수행 할 수 있으며 때로는 일부보기 논리도 수행 할 수 있습니다.
또한보십시오:
최소한의 형태로 다음과 같습니다.
- 모델 : 지속성 (Hibernate, JPA 등) 및 데이터 모델링 (Java Beans)에 사용하는 모든 것.
- 보기 : xhtml, jsp 등
- 컨트롤러 : Mananaged Beans.
JSF는 요청 / 응답을 제어 할 수있는 권한을 제공합니다. 모델 / 뷰를 생성하는 방식은 프레임 워크 MVC 개념에 직접 연결되지 않습니다. 그것은 단지 선택의 문제입니다. MVC 개념은 코드 구성과 관련이 있습니다.
유사하게 Struts는 MVC 프레임 워크이지만 주로 컨트롤러로 작동합니다.
나는 당신의 아이디어를 더 명확하게하는데 도움이 될 것 같습니다
관리 빈 아이디어의 흥미로운 점은 모델과 뷰가 상호 작용하지 않는 모델 (MVC 패턴) 또는 컨트롤러 ( mediating-controller MVC pattern , model-view-adapter라고도 함)로 사용할 수 있다는 것입니다. 직접.
후자의 경우 비즈니스 로직이 관리 빈에 포함되고 모델이 엄격하게 도메인 모델이기 때문에 라우팅 메커니즘은 컨트롤러가 아닙니다. 우리는 다음을 가지고 있습니다.
모델 -도메인 모델을 포함하며 대부분의 경우 DAO를 통해 유지되는 데이터베이스의 테이블을 나타냅니다.
보기 -빈에 연결된 UI 구성 요소
컨트롤러 -비즈니스 로직을 포함하고 뷰와 모델 간의 통신을 처리하는 관리 빈.
일부 사람들은 중재 컨트롤러 MVC를 일반 MVC로 혼동하여 다른 설명을 접하게됩니다.
여기있는 모든 anwsers가 맞다고 생각합니다. 그러나 혼란의 요점은 프레임 워크 (여기서는 JSF)에서 오는 mvc 구성 요소의 정의를 응용 프로그램 디자인에서 정의한 해당 모델 및 컨트롤러 구성 요소와 혼합하는 데서 발생합니다.
비즈니스 애플리케이션에서 JSF에서 다른 웹 UI 프레임 워크로 변경한다고 가정합니다. 여전히 "비즈니스 모델"과 "비즈니스 컨트롤러"가 있습니다. (우리 프로젝트에서는 이러한 구성 요소를 "모델"및 "프로세스"라고 부릅니다.) 이것이 의미하는 바 : 전체 애플리케이션 아키텍처에 대한 설명에 mvc를 사용할 수 없지만 UI에만 사용하거나 전체 애플리케이션 스택에서 구성 요소와 같은 많은 컨트롤러를 수용해야 할 수 있습니다.참조 URL : https://stackoverflow.com/questions/10111387/understanding-jsf-as-a-mvc-framework