Java Server Faces 2.0의 주요 단점은 무엇입니까?
어제 저는 현행 ASP.NET MVC / jQuery 개발자이지만 Java Server Faces 2.0에 대한 프레젠테이션을 보았습니다. JSF에서 가장 마음에 드는 것은 ASP.NET MVC보다 특히 AJAX가 많은 사이트에서 개발 속도가 훨씬 빨라지는 AJAX 지원 UI 구성 요소의 양이었습니다. 통합 테스트도 매우 좋아 보였다.
프레젠테이션은 JSF의 장점만을 강조했기 때문에 상대방에 대해서도 듣고 싶습니다.
그래서 내 질문은 :
- Java Server Faces 2.0의 주요 단점은 무엇입니까?
- JSF 개발자가 JSF 대신 ASP.NET MVC를 사용하도록 고려할 수있는 것은 무엇입니까?
JSF 2.0의 단점? 솔직히 기본 웹 개발 (HTML / CSS / JS, 서버 측 대 클라이언트 측 등) 및 기본 Java 서블릿 API (요청 / 응답 / 세션 ) 에 대한 배경 지식이없는 경우 상대적으로 가파른 학습 곡선을 제외하고 , 전달 / 리디렉션 등)에는 심각한 단점이 없습니다. 현재 릴리스의 JSF는 여전히 초기에 얻은 부정적인 이미지를 제거해야하며 몇 가지 심각한 단점이 있습니다.
JSF 1.0 (2004 년 3 월)
이것은 초기 릴리스였습니다. 그것은 당신이 알고 싶지 않은 핵심 영역과 성능 영역 모두에서 버그로 어수선했습니다. 직관적으로 예상 한대로 웹 애플리케이션이 항상 작동하지는 않았습니다. 개발자는 울부 짖을 것입니다.
JSF 1.1 (2004 년 5 월)
이것은 버그 픽스 릴리스입니다. 성능은 여전히 크게 향상되지 않았습니다. JSF 페이지에서 HTML을 완벽하게 인라인 할 수 없다는 단점도 있습니다. 모든 일반 바닐라 HTML 은 JSF 컴포넌트 트리 보다 먼저 렌더링됩니다 . <f:verbatim>JSF 컴포넌트 트리에 포함되도록 모든 일반 바닐라를 태그로 묶어야합니다. 이것은 사양에 따른 것이지만 많은 비판을 받았습니다. 또한 AO 참조 JSF / Facelets의를 : 왜 HTML 태그와 JSF / Facelets에 혼합하는 것은 좋은 생각이 아니다?
JSF 1.2 (2006 년 5 월)
Ryan Lubke가 이끄는 새로운 JSF 개발 팀의 첫 번째 릴리스입니다. 새로운 팀은 많은 훌륭한 일을했습니다. 사양도 변경되었습니다. 주요 변경 사항은 뷰 처리의 개선이었습니다. 이는 JSF를 JSP에서 완전히 분리했을뿐만 아니라 JSP와 다른 뷰 기술을 사용할 수있을뿐만 아니라 개발자는 <f:verbatim>태그를 사용 하지 않고도 JSF 페이지에서 일반 바닐라 HTML을 인라인 할 수있었습니다 . 새로운 팀의 또 다른 주요 초점은 성능 향상이었습니다. Sun JSF Reference Implementation 1.2 ( 2008 년경 빌드 1.2_08 이후 코드 명 Mojarra) 의 수명 동안 , 실질적으로 모든 빌드는 일반적인 (부수) 버그 수정 옆에 (주요) 성능 향상이 제공되었습니다.
JSF 1.x (1.2 포함)의 유일한 단점은 요청 과 세션 범위 (소위 대화 범위) 사이에 범위가 없다는 것입니다 . 이로 인해 개발자는 유효성 검사, 변환, 모델 변경 및 작업 호출을 성공적으로 처리하기 위해 후속 요청에서 초기 모델 데이터를 유지하려고 할 때마다 숨겨진 입력 요소, 불필요한 DB 쿼리 및 / 또는 세션 범위를 남용해야했습니다. 복잡한 웹 애플리케이션. MyFaces Tomahawk <t:saveState> 구성 요소, JBoss Seam 대화 범위 및 MyFaces 오케스트라 와 같은 후속 요청에서 필요한 데이터를 보유하는 써드 파티 라이브러리를 채택하여 고통을 완화 할 수 있습니다. 대화 프레임 워크.
HTML / CSS 순수 주의자의 또 다른 단점은 JSF가 콜론 :을 ID 구분 문자로 사용 id하여 생성 된 HTML 출력에서 HTML 요소의 고유성을 보장한다는 것입니다. 특히 뷰에서 구성 요소를 두 번 이상 재사용 할 때 (템플릿, 구성 요소 반복 등) . 이 CSS 식별자에 잘못된 문자이기 때문에, 당신은을 사용해야합니다 \같은 추한 및 홀수 찾고 선택기의 결과로, CSS 선택기에서 콜론을 탈출 #formId\:fieldId {}하거나 #formId\3A fieldId {}. CSS 선택기에서 콜론 ":"과 함께 JSF 생성 HTML 요소 ID를 사용하는 방법 도 참조하십시오 . 그러나 순수하지 않은 경우 기본적으로 JSF는 사용할 수없는 ID를 생성하며 이는 웹 표준의 css 부분과 호환되지 않습니다 .
또한 JSF 1.x는 기본적으로 Ajax 기능과 함께 제공되지 않았습니다. 실제로 기술적 인 단점은 아니지만 그 기간 동안 Web 2.0 과대 광고로 인해 기능상의 단점이되었습니다. Exadel 은 초기에 Ajax4jsf를 도입하기 시작했으며 수년간 철저히 개발되어 JBoss RichFaces 컴포넌트 라이브러리 의 핵심 부분이되었습니다 . 또 다른 구성 요소 라이브러리에는 내장 된 Ajax 기능이 포함되어 있으며 잘 알려진 것은 ICEfaces 입니다.
JSF 1.2 수명의 절반 쯤에 새로운 XML 기반 뷰 기술인 Facelets 가 도입되었습니다 . 이는 특히 템플릿 영역에서 JSP보다 큰 이점을 제공했습니다.
JSF 2.0 (2009 년 6 월)
이것은 Ajax를 유행어로 사용하는 두 번째 주요 릴리스입니다. 많은 기술적, 기능적 변화가있었습니다. JSP는 기본보기 기술로 Facelets로 대체되었으며 Facelets는 순수 XML (소위 복합 컴포넌트 )을 사용하여 사용자 정의 컴포넌트를 작성하는 기능으로 확장되었습니다 . JSF2.0 이후의 뷰 정의 언어로 Facelets가 JSP보다 선호되는 이유 는 무엇입니까?
Ajax 기능은 <f:ajax>Ajax4jsf와 매우 유사한 구성 요소의 풍미에 도입되었습니다 . 자세한 정보 파일을 최대한 많이 종료 하기 위해 주석 및 구성에 대한 컨벤션 개선 사항이 도입되었습니다 faces-config.xml. 또한 기본 이름 지정 컨테이너 ID 구분 기호 문자를 :구성 할 수있게되어 HTML / CSS 순수 주의자가 안심할 수 있습니다. 당신이 할 필요가로 정의하는 것입니다 init-param의 web.xml이름으로 javax.faces.SEPARATOR_CHAR당신과 같은 클라이언트 ID 년대에 아무 곳이나 문자를 직접 사용하고 있지 않은지 및 보장 -.
마지막으로 새로운 범위 인 뷰 범위 가 도입되었습니다 . 앞에서 설명한 것처럼 또 다른 주요 JSF 1.x 단점을 제거했습니다. @ViewScoped후속 (대화식) 요청에서 데이터를 유지하는 모든 방법을 번거롭게하지 않고 대화 범위를 사용 하도록 Bean 을 선언하기 만하면 됩니다. @ViewScoped이후에 제출하고 동일한보기로 이동하고 같은 콩은 오래 살 것이다 (독립적으로 열린 브라우저 탭 / 창!), 동 기적 또는 비동기 (아약스). 참고 관리 콩보기 및 요청 범위의 차이 와 어떻게 바로 콩 범위를 선택하는 방법을?
JSF 1.x의 실질적인 모든 단점이 제거되었지만, JSF 2.0 특정 버그가 있습니다. 는 @ViewScoped태그 핸들러에서 실패 로 인해 부분적인 상태 절약에 닭이 먼저 냐 달걀이 먼저 냐의 문제에. 이것은 JSF 2.2에서 수정되었으며 Mojarra 2.1.18에서 백 포트되었습니다. 또한 HTML5와 같은 사용자 정의 속성 전달data-xxx 은 지원되지 않습니다. 이것은 새로운 통과 요소 / 속성 기능에 의해 JSF 2.2에서 수정되었습니다. 또한 JSF 구현 Mojarra는 고유 한 문제를 가지고 있습니다 . 상대적으로 많은 부분이 때때로 직관적이지 않은 동작<ui:repeat> , 새로운 부분 상태 저장 구현 및 잘못 구현 된 플래시 범위와 관련이 있습니다. 대부분은 Mojarra 2.2.x 버전으로 수정되었습니다.
JSF 2.0 시간 에 jQuery 및 jQuery UI를 기반으로 PrimeFaces 가 도입되었습니다. 가장 인기있는 JSF 컴포넌트 라이브러리가되었습니다.
JSF 2.2 (2013 년 5 월)
JSF 2.2가 도입되면서 HTML5는 모든 이전 JSF 버전에서 기술적으로 만 지원되었지만 유행어로 사용되었습니다. JavaServer Faces 2.2 및 HTML5 지원을 참조하십시오 . 왜 XHTML이 여전히 사용되고 있습니까 ? 가장 중요한 새로운 JSF 2.2 기능은 커스텀 테이블리스 라디오 버튼 그룹 과 같은 가능성을 열어주는 커스텀 컴포넌트 속성을 지원하는 것입니다 .
구현 특정 버그와 유효성 검사기 / 변환기 (JFS 2.3에서 이미 수정 된)에 EJB를 주입 할 수없는 것과 같은 일부 "성가신 작은 것"외에도 JSF 2.2 사양에는 큰 단점이 없습니다.
컴포넌트 기반 MVC 및 요청 기반 MVC
JSF의 주요 단점은 생성 된 HTML / CSS / JS에 대한 세밀한 제어가 거의 불가능하다는 것입니다. 이는 JSF 자체가 아니며 요청 기반 (액션) 기반 MVC 프레임 워크가 아니라 컴포넌트 기반 MVC 프레임 워크 이기 때문 입니다. MVC 프레임 워크를 고려할 때 HTML / CSS / JS를 높은 수준으로 제어하는 것이 주요 요구 사항이라면 이미 컴포넌트 기반 MVC 프레임 워크를 보지 말고 Spring MVC 와 같은 요청 기반 MVC 프레임 워크를 살펴보아야합니다 . HTML / CSS / JS 상용구를 직접 작성해야한다는 점만 고려하면됩니다. 요청 MVC와 컴포넌트 MVC의 차이점 도 참조하십시오 .
또한보십시오:
- JSF, Servlet 및 JSP의 차이점은 무엇입니까? (기본을 이해하기 위해)
- JSF를 사용하여 테이블리스 CSS 레이아웃 개발 (JSF에 대한 또 다른 신화)
- JSF vs 일반 HTML / CSS / JS / jQuery (JSF가 잘못된 선택 인 경우)
- 웹 애플리케이션의 디자인 패턴 (MVC의 이념을 설명)
JSF와 5 년간 일한 후 2 센트를 더할 수 있다고 생각합니다.
두 가지 주요 JSF 단점 :
- 큰 학습 곡선. JSF는 복잡하지만 사실입니다.
- 그것의 구성 요소 자연을. 컴포넌트 기반 프레임 워크는 웹의 진정한 본질을 숨기려고 시도하는데, 이는 거의 5 년 내에 JSF에서 GET을 지원하지 않는 등 엄청난 양의 합병증과 재난이 발생합니다.
개발자로부터 HTTP 요청 / 응답을 숨기는 IMHO는 엄청난 실수입니다. 필자의 경험에 따르면 모든 구성 요소 기반 프레임 워크는 웹 개발에 추상화를 추가하며이 추상화는 불필요한 오버 헤드와 복잡성을 초래합니다.
그리고 내 마음에 오는 사소한 단점 :
- 기본적으로 개체의 ID는 부모의 ID로 구성됩니다 (예 : form1 : button1).
- 잘못된 페이지 조각을 주석 처리하는 쉬운 방법은 없습니다. 태그
<ui:remove>는 구문 분석 된 내용을 구문 적으로 수정해야합니다. - 예를 들어 계속하기 전에
isRendered()내부processXxx()방법을 확인하지 않는 저품질 타사 구성 요소 . - LESS & Sencha 통합은 어렵습니다.
- REST와 잘 어울리지 않습니다.
- 즉시 사용 가능한 구성 요소에는 고유 한 CSS 스타일이 있으므로 덮어 쓸 필요가 있으므로 UX 디자이너에게는 그리 쉬운 일이 아닙니다.
내가 틀리지 마 구성 요소 프레임 워크로서 JSF 버전 2는 정말 좋지만 여전히 구성 요소 기반이며 항상 ...
Tapestry, Wicket의 인기가 낮고 경험 많은 JSF 개발자의 열의가 적습니다 (더 의미있는 것). 대조적으로 Rails, Grails, Django, Play의 성공을 살펴보십시오! 프레임 워크-모두 액션 기반이며 웹 의 프로그래머의 진정한 요청 / 응답 및 상태 비 저장 특성 을 숨기려고 시도하지 않습니다 .
나를 위해 그것은 주요 JSF 단점입니다. IMHO JSF는 일부 유형의 응용 프로그램 (인트라넷, 양식 집약적)에 적합 할 수 있지만 실제 웹 응용 프로그램에는 적합하지 않습니다.
프론트 엔드와 관련하여 자신의 선택에 도움이되기를 바랍니다.
떠오르는 몇 가지 단점 :
- JSF는 컴포넌트 기반 프레임 워크입니다. 이것은 구성 요소 모델을 준수하는 것과 관련된 고유 제한 사항이 있습니다.
- AFAIK JSF는 POST 만 지원하므로 GET을 원하면 일반 서블릿 / JSP를 수행해야합니다.
- 대부분의 구성 요소는 관계형 데이터베이스 및 프런트 엔드 JavaScript와 같은 도메인에 대한 추상화를 제공하려고 시도하며, 이러한 추상화는 "쉽고"디버깅하기가 매우 어렵습니다.
- 이러한 추상화는 하급 개발자 나 특정 도메인 (예 : 프론트 엔드 JavaScript)에 익숙하지 않은 사람에게는 좋은 출발점이 될 수 있지만 관련된 여러 계층이 있고 대부분의 사람들이이를 사용하므로 성능을 최적화하기가 매우 어렵습니다. 후드 아래에서 무슨 일이 일어나고 있는지 거의 이해하지 못합니다.
- 일반적으로 JSF와 함께 사용되는 템플릿 메커니즘은 웹 desiger가 작동하는 방식과 관련이 없습니다. JSF 용 WYSIWYG 편집기는 기본적이며 어쨌든 디자이너는 변환에 오랜 시간을 소비해야하는 HTML / CSS를 제공합니다.
- EL 표현식과 같은 것들은 정적으로 검사되지 않으며 컴파일러와 IDE 모두 오류를 찾는 데 제대로 작동하지 않으므로 런타임에 포착 해야하는 오류가 발생합니다. 루비 또는 PHP와 같이 동적으로 유형이 지정된 언어에는 적합 할 수 있지만 Java 생태계의 급증을 견뎌야하는 경우 템플릿을 입력해야합니다.
요약하자면 , JSP / servlet / bean 상용구 코드 작성을 피하는 것에서 JSF로 절약 할 시간을 x10으로 확장하여 원하는대로 정확하게 수행 할 수 있습니다.
JSF 2.0의 가장 큰 단점은 JSF뿐만 아니라 유용한 작업을 수행하기 위해 사용해야하는 구성 요소 라이브러리라는 학습 곡선입니다. 실제로 숙달하기 위해 다루고있는 엄청난 수의 사양과 표준을 고려하십시오.
- 다양한 화신의 HTML. 모르는 척하지 마십시오.
- HTTP-무슨 일이 일어나고 있는지 알 수 없으면 Firebug를 열어 봐야합니다. 이를 위해서는 이것을 알아야합니다.
- CSS-좋아하든 없든 실제로 그렇게 나쁘지는 않으며 적어도 멋진 도구가 있습니다.
- XML-JSF는 아마도 네임 스페이스를 가장 먼저 사용할 것입니다.
- 서블릿 사양. 조만간이 패키지에서 메소드를 호출하게됩니다. 그 외에도 Facelets가 XHTML 등으로 바뀌는 방법을 알아야합니다.
- JSP (주로 JSF에서 왜 필요하지 않은지 알 수 있습니다)
- JSTL (다시 레거시 프레임 워크에 대처하기 위해)
- 다양한 형태의 표현 언어 (EL).
- ECMAScript, JavaScript 또는 기타 원하는 기능.
- JSON-사용하지 않더라도이를 알아야합니다.
- AJAX. JSF 2.0이 이것을 숨기려는 적절한 일을하지만 여전히 무슨 일이 일어나고 있는지 알아야합니다.
- DOM. 그리고 브라우저가 그것을 사용하는 방법. ECMAScript를 참조하십시오.
- DOM 이벤트-주제 자체.
- JPA (Java Persistence Architecture)는 앱에 백엔드 데이터베이스가 포함되도록하려는 경우입니다.
- 자바 자체.
- 당신이 그것에있는 동안 JSEE.
- CDI (Context Dependency Injection Specification) 및 JSF 2.0과 충돌하고 사용되는 방법
- JQuery-나는 당신이 그것없이 잘 지내고 싶습니다.
이제 일단 완성되면 독점 사양, 즉 구성 요소 라이브러리 및 공급자 라이브러리를 사용할 수 있습니다.
- PrimeFaces (내 컴포넌트 라이브러리 선택)
- 리치 페이스
- MyFaces
- 아이 스페이스
- EclipseLink (내 JPA 제공자)
- 동면
- 용접
그리고 용기를 잊지 마십시오! 그리고 모든 구성 파일 :
- GlassFish (2, 3 등)
- 제이보스
- 수코양이
그래서-이것은 쉬운 일입니까? 물론 JSF 2.0은 가장 간단한 상호 작용이있는 가장 기본적인 웹 페이지 만 있으면 "쉽습니다".
간단히 말해 JSF 2.0은 오늘날 소프트웨어 세계에 존재하는 것처럼 서로 결합 된 기술 중 가장 복잡하고 번거로운 혼란입니다. 그리고 나는 내가 사용하려는 것을 생각할 수 없습니다.
- 경험이 부족한 개발자는 일반적으로 고통스럽게 느린 응용 프로그램을 만들고 코드가 실제로 추악하고 유지 관리하기가 어렵습니다. 시작하기는 매우 간단하지만 실제로 좋은 프로그램을 작성하려면 학습에 약간의 투자가 필요합니다.
- 적어도 처음에는 종종 어떤 문제에 "고착"되어 실제로 작업하는 것보다 인터넷에서 balusc 게시물을 읽는 데 더 많은 시간을 소비 할 것입니다.
- 문제가 지식 / 실수 부족이 아니라 실제로 버그로 인한 것임을 알게되면 더욱 성가신 일입니다. Mojarra는 상당히 버그가 많았으며 다른 구성 요소 레이어로 인해 더 많은 문제가 발생합니다. Richfaces는 지금까지 작성된 쓰레기 소프트웨어 중 가장 큰 조각이었습니다. :) 현재 버전 4에 대한 방법을 모릅니다. Primefaces가 더 우수하지만 여전히 더 이국적인 구성 요소로 인해 버그가 발생하거나 기능이 부족합니다. 이제 Primefaces 업데이트 비용을 지불해야합니다. 그래서 나는 버그가 있지만 2.2 버전 이후에 점점 좋아지고 스펙에 대한 일부 문제를 수정했습니다. 프레임 워크는 점점 성숙해 지지만 여전히 완벽하지는 않습니다 (어쩌면 내 얼굴이 더 좋을까요?).
- 특히 유연하지 않습니다. 종종 매우 맞춤화 된 것이 필요하고 그렇게하는 구성 요소가없는 경우 약간 고통 스럽습니다. 다시 말하지만 나는 일반적인 개발자 관점에서 이야기합니다. 마감일, 빠른 읽기 자습서 및 스택 오버 플로우가 실제로 작동하는 방법을 배울 시간이 없기 때문에 멈출 때 검색하는 경우가 있습니다. 정확하고 때로는 당신이 원하는 것을하기 위해 너무 많은 시간을 소비 할 수도 있습니다. :) 자신의 것을 만들거나 기존의 구성 요소를 고문하는 것이 더 나은지 평가할 때주의해야합니다. 실제로 당신이 정말로 독특한 것을 만들고 있다면 JSF를 권장하지 않을 것입니다.
요컨대 내 단점은 복잡성, 개발 진행이 매끄럽지 않고 버그가 많고 유연하지 않다는 것입니다.
물론 장점도 있지만 그것은 당신이 요구 한 것이 아닙니다. 어쨌든 내 프레임 워크에 대한 나의 경험은 다른 사람들이 다른 의견을 가질 수 있으므로 가장 좋은 방법은 잠시 동안 시도해보고 당신을 위해 그것을 시도하는 것입니다 (순진한 예제가 아닌 더 복잡한 것-JSF가 실제로 빛납니다 :) IMHO의 가장 좋은 사용 사례 JSF는 CRM 등과 같은 비즈니스 응용 프로그램입니다.
"JSF는 컨트롤러 코드에 들어 가지 않고 제어하거나 변경할 수없는 View-layer HTML 및 JavaScript를 출력합니다."
실제로 JSF는 유연성을 제공하므로 표준 / 타사 구성 요소를 사용하거나 렌더링 대상을 완전히 제어 할 수있는 자체 구성 요소를 만들 수 있습니다. JSF 2.0으로 커스텀 컴포넌트를 만드는 데 필요한 하나의 xhtml입니다.
우리는 JSF로 샘플 프로젝트를 개발했습니다.
핵심 jsf를 사용하려고합니다. 컴포넌트가 필요한 경우 PrimeFaces를 사용했습니다.
프로젝트는 탐색 기능이있는 웹 사이트였습니다. 메뉴를 클릭 할 때 각 페이지는 ajax를 통해로드되어야합니다.
이 사이트에는 두 가지 사용 사례가 있습니다.
- 격자가있는 페이지입니다. 그리드는 아약스를 통해로드되며 정렬 및 페이징을 지원해야합니다.
- 3 단계 마법사 페이지 각 페이지에는 클라이언트 측 유효성 검사 (간단한 유효성 검사)와 서버 측 아약스 기본 유효성 검사 (복잡한 유효성 검사)가 있습니다. 다음 페이지로 이동하지 않고 서비스 계층의 모든 서버 예외가 동일한 마법사 페이지에 표시되어야합니다.
우리는 그것을 발견했다 :
- JSF보기 상태를 수정하려면 omniFaces의 일부 해킹을 사용해야합니다. 서로에 ajax를 통해 페이지를 포함 시키면 JSF 상태가 손상됩니다. 이것은 JSF의 버그로 보이며 다음 릴리스 (2.3이 아닌)에서 수정 될 수 있습니다.
- JSF 플로우가 ajax에서 올바르게 작동하지 않거나 작동하지 않을 수 있습니다. 대신 Primface Wizard 구성 요소를 사용하려고 시도하지만 클라이언트 유효성 검증이 지원되지 않는 것으로 보이며 표준 JSF 플로우 표준이 아닌 동안 의미합니다.
- jqGird와 같은 일부 jQuery 컴포넌트를 사용하고 JSON 결과를로드해야하는 경우 순수 서블릿을 사용하는 것이 좋습니다. JSF는 사용자를 위해 아무 것도하지 않습니다. 따라서 이러한 종류의 구성 요소를 사용하면 디자인이 JSF에 적합하지 않습니다.
- 우리는 ajax가 완료 될 때 일부 클라이언트 스크립트를 시도
ajaxComplete하고 PF 4가 자체 ajax 이벤트를 구현 한 것을 발견했습니다. 우리는 jQuery 컴포넌트를 가지고 있었고 코드를 변경해야합니다.
위의 샘플을 Ajax 이외의 프로젝트 (또는 최소한 적은 ajax 프로젝트)로 변경하면 위의 많은 문제에 직면하지 않습니다.
우리는 우리의 연구를 다음과 같이 요약합니다 :
JSF는 완전한 아약스 기반 웹 사이트에서 잘 작동하지 않습니다.
물론 JSF에는 일부 프로젝트에 매우 유용한 유용한 기능이 많이 있으므로 프로젝트 요구 사항을 고려하십시오.
JSF의 장점을 검토하려면 JSF 기술 문서를 참조하십시오. 제 생각에 JSF의 가장 큰 장점은 @BalusC의 완벽하고 거대한 지원입니다.
저는 Java Server Faces 전문가가 아닙니다. 그러나 IMHO의 주요 단점은 서버 측이라는 것입니다. ASP.NET Web Forms, ASP.NET MVC, Java Server Faces, Struts, php 프레임 워크 및 ruby on rails 프레임 워크와 같은 서버 측 웹 프리젠 테이션 계층 프레임 워크를 배우고 사용하는 데 지쳤습니다. 나는 그들 모두에게 작별 인사를하고 Angularjs와 TypeScript에게 인사했습니다. 내 프리젠 테이션 레이어가 브라우저에서 실행됩니다. PHP 또는 ASP.NET을 실행하는 Windows IIS에서 제공되는지 또는 Linux에서 실행되는 Apache 웹 서버에서 제공되는지는 중요하지 않습니다. 모든 곳에서 작동하는 하나의 프레임 워크 만 배우면됩니다.
내 두 센트.
저에게 JSF의 가장 큰 단점은 프로그래밍 방식으로 (동적으로) 생성 된 페이지에 대한 지원이 부족하다는 것입니다.
Java 코드에서 동적으로 페이지를 구성하려면 (페이지 컴포넌트 모델 작성). 예를 들어 WYSIWYG 웹 페이지 생성자에서 작업중인 경우. 이 유스 케이스에 대한 적절한 문서는 일반적으로 사용 가능하지 않습니다. 실험해야 할 점이 많으며 개발 속도가 느립니다. 많은 것들이 예상대로 작동하지 않습니다. 그러나 일반적으로 가능한 방법은 그것을 해킹합니다.
JSF의 철학이나 아키텍처에서는 문제가되지 않는다는 것이 좋습니다. 그것은 충분히 정교하지 않습니다 (내가 아는 한).
JSF 2는 컴포지트 컴포넌트를 가져 와서 컴포넌트 개발을 용이하게하지만 동적 (프로그래밍 방식) 구성에 대한 지원은 매우 열악합니다. 조용하고 복잡하고 문서화되지 않은 동적 컴포지트 구성 요소 구성 프로세스를 극복하면 컴포지트 구성 요소를 조금 더 깊게 중첩하면 작동이 중지되고 일부 예외가 발생합니다.
그러나 JSF 커뮤니티는이 단점을 알고있는 것 같습니다. 그들은이 두 가지 버그에서 볼 수
있듯이이 작업을하고 있습니다 http://java.net/jira/browse/JAVASERVERFACES-1309
http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-599
사양에 대해 이야기하고 있다면 JSF 2.2의 상황은 더 좋을 것입니다.
지난 몇 달 동안 Primefaces / JSF 경험에 대한 논평 :
- "선반 외부"구성 요소를 사용할 수 있다면 끔찍하지 않은 것 같습니다.
- 그러나 밖으로 나가서 사용자 정의 UI가 필요한 즉시 제대로 작동하지 않습니다. -예를 들어 프로젝트에 트위터 부트 스트랩을 사용해야했습니다. (머리말 부트 스트랩이 아님).
- 이제 우리의 페이지는 다음과 같이 작동합니다.
- 페이지가로드되었습니다.
- 사용자는 아약스 기능이있는 Primefaces와 상호 작용
- 부트 스트랩의 자바 스크립트 바인딩 중단
- 우리는 모든 것을 리 바인드하기 위해 추가 자바 스크립트를 실행합니다.
- 이제 우리의 페이지는 다음과 같이 작동합니다.
자바 스크립트 작성을 피하겠다는 JSF의 약속은 Primefaces를 사용하지 않을 때보 다 더 많은 자바 스크립트를 작성하는 것으로 바뀌 었습니다. 그리고 그 자바 스크립트는 Primefaces가 깨지는 것을 수정하는 것입니다.
다시 "선반에서"물건을 사용하지 않는 한 시간이 흐릅니다. 또한 Selenium과 작업해야 할 때 정말 추악합니다 (Primefaces). 이 모든 것이 가능하지만 시간이 너무 많습니다.
UX / 디자인 팀과 함께 작업하고 UI를 빠르게 반복해야하는 경우 확실히 피하십시오. jquery를 배우거나 HTML을 작성하거나 반응 / 각도를 살펴보면 시간을 절약 할 수 있습니다.
JSF에는 많은 장점이 있습니다. 불이익에 대한 의문은 몇 가지 요점을 추가 할 수 있습니다.
일정 시간 안에 웹 프로젝트를 구현하는 실제 시나리오에서는 다음 요소를 주시해야합니다.
- 각 시나리오에 적합한 최상의 제어 방법을 제안 할 수있는 충분한 선임 구성원이 팀에 있습니까?
초기 학습 곡선을 수용 할 수있는 대역폭이 있습니까?
개발자가 제작 한 JSF 자료를 검토 할 수있는 충분한 전문 지식이 팀에 있습니까?
질문에 대한 답변이 '아니요'인 경우 유지 관리 할 수없는 코드베이스가 될 수 있습니다.
JSF에는 한 가지 단점이 있습니다. "JSF"개발을 시작하기 전에 웹 개발, 핵심 Java 및 프론트 엔드 아키텍처를 명확하게 이해해야합니다.
요즘 "새로운"JavaScript 프레임 워크는 "JSF"컴포넌트 기반 모델을 복사 / 붙여 넣기 만하면됩니다.
Spring MVC, Wicket, Tapestry 등과 같은 모든 "주류"프레임 워크 중에서 복합 컴포넌트를 포함한 Java EE의 JSF는 가장 정교한 프리젠 테이션 계층 및 컴포넌트 지향 기술입니다. HybridJava가 제공하는 솔루션에 비해 약간 번거롭고 불완전합니다.
참고 URL : https://stackoverflow.com/questions/3623911/what-are-the-main-disadvantages-of-java-server-faces-2-0
'Programing' 카테고리의 다른 글
| jQuery를 사용하여 알파벳순으로 목록을 정렬하려면 어떻게해야합니까? (0) | 2020.04.15 |
|---|---|
| 명령 줄 매개 변수를 구문 분석하는 가장 좋은 방법은 무엇입니까? (0) | 2020.04.15 |
| Wi-Fi가 Android에 연결되어 있는지 어떻게 알 수 있습니까? (0) | 2020.04.15 |
| YouTube 동영상 퍼가기 (0) | 2020.04.15 |
| 열거 형 항목의 이름을 얻는 방법? (0) | 2020.04.15 |