[asp.net-mvc] Java Server Faces 2.0의 주요 단점은 무엇입니까?

Program / 글쓴이

어제 저는 현행 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 : JSF / Facelet을 HTML 태그와 혼합하는 것은 왜 좋지 않은가?

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 기능은 커스텀 테이블리스 라디오 버튼 그룹 과 같은 가능성을 열어주는 커스텀 컴포넌트 속성에 대한 지원입니다 .

구현 특정 버그와 유효성 검사기 / 변환기에 EJB를 주입 할 수없는 것과 같은 일부 “성가신 작은 것”(이미 JSF 2.3에서 수정 됨) 외에도 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와 5 년간 일한 후 2 센트를 더할 수 있다고 생각합니다.

두 가지 주요 JSF 단점 :

  1. 큰 학습 곡선. JSF는 복잡하지만 사실입니다.
  2. 그것의 구성 요소 자연을. 컴포넌트 기반 프레임 워크는 웹의 진정한 본질을 숨기려고 시도하는데, 이는 거의 5 년 내에 JSF에서 GET을 지원하지 않는 등 엄청난 양의 합병증과 재난이 발생합니다.

    개발자로부터 HTTP 요청 / 응답을 숨기는 IMHO는 엄청난 실수입니다. 내 경험에 따르면 모든 구성 요소 기반 프레임 워크는 웹 개발에 추상화를 추가하며, 이러한 추상화는 불필요한 오버 헤드와 더 높은 복잡성을 초래합니다.

그리고 내 마음에 오는 사소한 단점 :

  1. 기본적으로 개체의 ID는 부모의 ID로 구성됩니다 (예 : form1 : button1).
  2. 잘못된 페이지 조각을 주석 처리하는 쉬운 방법은 없습니다. 태그 <ui:remove>는 구문 분석 된 내용을 구문 적으로 수정해야합니다.
  3. 예를 들어 계속하기 전에 isRendered()내부 processXxx()방법을 확인하지 않는 저품질 타사 구성 요소 .
  4. LESS & Sencha 통합은 어렵습니다.
  5. REST와 잘 어울리지 않습니다.
  6. 즉시 사용 가능한 구성 요소에는 고유 한 CSS 스타일이 있으므로 덮어 쓸 필요가 있으므로 UX 디자이너에게는 그리 쉬운 일이 아닙니다.

내가 틀리지 마 컴포넌트 프레임 워크로서 JSF 버전 2는 정말 훌륭하지만 여전히 컴포넌트 기반이며 항상 …

Tapestry, Wicket의 인기가 낮고 숙련 된 JSF 개발자의 열의가 적습니다 (더 의미있는 내용). 대조적으로 Rails, Grails, Django, Play의 성공을 살펴보십시오! 프레임 워크-모두 액션 기반이며 웹 의 프로그래머의 진정한 요청 / 응답 및 상태 비 저장 특성 을 숨기려고 시도하지 않습니다 .

나를 위해 그것은 주요 JSF 단점입니다. IMHO JSF는 일부 유형의 응용 프로그램 (인트라넷, 양식 집약적)에 적합 할 수 있지만 실제 웹 응용 프로그램에는 적합하지 않습니다.

프론트 엔드와 관련하여 자신의 선택에 도움이되기를 바랍니다.

답변

떠오르는 몇 가지 단점 :

  1. JSF는 컴포넌트 기반 프레임 워크입니다. 이것은 구성 요소 모델을 따르는 것과 관련된 고유 제한 사항이 있습니다.
  2. AFAIK JSF는 POST 만 지원하므로 GET을 원하면 일반 서블릿 / JSP를 수행해야합니다.
  3. 대부분의 구성 요소는 관계형 데이터베이스 및 프런트 엔드 JavaScript와 같은 도메인에 대한 추상화를 제공하려고 시도하며, 이러한 추상화는 “쉽고”디버그하기가 매우 어려운 경우가 많습니다.
  4. 이러한 추상화는 하급 개발자 나 특정 도메인 (예 : 프론트 엔드 JavaScript)에 익숙하지 않은 사람에게는 좋은 출발점이 될 수 있지만 관련된 여러 계층이 있고 대부분의 사람들이이를 사용하므로 성능을 최적화하기가 매우 어렵습니다. 후드 아래에서 무슨 일이 일어나고 있는지 거의 이해하지 못합니다.
  5. 일반적으로 JSF와 함께 사용되는 템플릿 메커니즘은 웹 desiger의 작동 방식과 관련이 없습니다. JSF 용 WYSIWYG 편집기는 기본적이며, 어쨌든 디자이너는 변환에 오랜 시간을 소비해야하는 HTML / CSS를 제공합니다.
  6. EL 표현식과 같은 것들은 정적으로 검사되지 않으며 컴파일러와 IDE 모두 오류를 찾는 데 제대로 작동하지 않으므로 런타임에 포착 해야하는 오류가 발생합니다. Ruby 또는 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은 오늘날 소프트웨어 세계에 존재하는 것처럼 서로 결합 된 기술 중 가장 복잡하고 번거로운 혼란입니다. 그리고 나는 내가 사용하려는 것을 생각할 수 없습니다.

답변

  1. 경험이없는 개발자는 일반적으로 고통스럽게 느린 응용 프로그램을 만들고 코드가 실제로 추악하고 유지 관리하기가 어렵습니다. 시작하기는 매우 간단하지만 실제로 좋은 프로그램을 작성하려면 학습에 약간의 투자가 필요합니다.
  2. 적어도 처음에는 종종 어떤 문제에 “고착”되어 인터넷에서 실제로 작동하는 것보다 balusc 게시물을 읽는 데 더 많은 시간을 할애합니다 🙂 잠시 후에는 점점 줄어들 것입니다. 그러나 여전히 성 가실 수 있습니다.
  3. 문제가 지식 / 실수가 아니라 실제로 버그로 인한 것임을 알게되면 더욱 성 가실 수 있습니다. Mojarra는 매우 버그가 많았으며 다른 구성 요소 레이어로 인해 더 많은 문제가 발생합니다. Richfaces는 지금까지 작성된 쓰레기 소프트웨어 중 가장 큰 조각이었습니다. 🙂 현재 버전 4에서 어떻게 작동하는지 알지 못합니다. Primefaces가 더 우수하지만 여전히 더 이국적인 구성 요소로 인해 버그가 발생하거나 기능이 부족합니다. 이제 Primefaces 업데이트 비용을 지불해야합니다. 그래서 나는 버그가 있지만 2.2 버전 이후에 점점 좋아지고 사양에 대한 일부 문제를 해결했습니다. 프레임 워크는 점점 성숙해 지지만 여전히 완벽하지는 않습니다 (어쩌면 내 얼굴이 더 좋을까요?).
  4. 특히 유연하지 않습니다. 종종 매우 맞춤화 된 것이 필요하고 그렇게하는 구성 요소가없는 경우 약간 고통 스럽습니다. 다시 말하지만 나는 일반적인 개발자 관점에서 이야기합니다. 마감일, 빠른 읽기 자습서 및 스택 오버 플로우가 실제로 작동하는 방법을 배울 시간이 없기 때문에 멈출 때 검색하는 경우가 있습니다.) 일부 구성 요소는 종종 “거의”필요한 것으로 보이지만 정확하고 때로는 당신이 원하는 일을하는데 너무 많은 시간을 소비 할 수도 있습니다. 실제로 당신이 정말로 독특한 것을 만들고 있다면 JSF를 권장하지 않을 것입니다.

요컨대 내 단점은 복잡성, 개발 진행이 매끄럽지 않고 버그가 많고 유연하지 않다는 것입니다.

물론 장점도 있지만 그것은 당신이 요구 한 것이 아닙니다. 어쨌든 내 프레임 워크에 대한 나의 경험은 다른 사람들이 다른 의견을 가질 수 있으므로 가장 좋은 방법은 잠시 동안 시도해보고 당신을 위해 그것을 시도하는 것입니다 (순진한 예제가 아닌 더 복잡한 것-JSF가 실제로 빛납니다 🙂 JSF는 CRM 등과 같은 비즈니스 응용 프로그램입니다.

답변

“JSF는 컨트롤러 코드로 들어 가지 않고 제어하거나 변경할 수없는 View-layer HTML 및 JavaScript를 출력합니다.”

실제로 JSF는 유연성을 제공합니다. 표준 / 타사 구성 요소를 사용하거나 렌더링 대상을 완전히 제어 할 수있는 자체 구성 요소를 만들 수 있습니다. JSF 2.0으로 커스텀 컴포넌트를 만드는 데 필요한 하나의 xhtml입니다.

답변

저는 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 웹 서버에서 제공되는지는 중요하지 않습니다. 모든 곳에서 작동하는 하나의 프레임 워크 만 배우면됩니다.

내 두 센트.