Java Server Faces 2.0의 주요 단점은 무엇입니까?


234

어제 저는 현행 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를 사용하도록 고려할 수있는 것은 무엇입니까?

2
솔직히 우리는이 모든 컴포넌트 인 Bean, "feature"쓰레기를 제거하고 일반 코딩으로 돌아 가야합니다. 나는 나를 위해 모든 것을하려고하고 (그리고 끔찍하게 추가 할 수있는) 두꺼운 프레임 워크를 원하지 않고 실제로 아래에서 일어나고있는 것과 멀어지게합니다. TypeScript를 살펴보고 그에 맞는 매우 얇은 코드 레이어를 찾아보십시오. JSF / PF와 친구들은 많은 "기능"을 가지고 있지만, 당신은 그들 주위를 돌아 다니면서 원하는 것을하기 위해 올바른 마법 속성 코드 나 트리 레이아웃을 알아야합니다.
Andrew

답변:


464

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-paramweb.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의 차이점 도 참조하십시오 .

또한보십시오:


5
범위와 관련하여 : Java EE 6에서는 요청을 다른보기로 확장하는 범위를 사용할 수도 있습니다. 이것이 CDI 대화 범위입니다. 기술적으로 JSF의 일부는 아니지만 JSF와 잘 통합되어 기본 JSF 기능처럼 느껴집니다.
Arjan Tijms

3
그럼에도 불구하고 ui : repeat는 수정되어야하며 두 구현에서 중첩 된 h : dataTable + ajax 관련 버그는 1 년이 넘는 릴리스 이후에 한심합니다. 연민 정말, 두 문제 I가 JSF 2.0를 추천하지 않을 경우 때문에 사람 으로 모든 웹 응용 프로그램 개발을위한 솔루션을 제공합니다.
fdreger

1
좋은 대답이지만 테스트에 대한 몇 가지 주장을 놓친 것 같습니다. JSF는 테스트하기 어렵다. ASP.NET MVC는 TDD 준비가되었습니다.
Guaido79

14
나는 20 년의 JAVA / WEB 경험을 가지고 있으며 JSF를 사용하는 모든 프로젝트를 거부하고 기분 나쁘게 느끼지 말고 JSF는 모든 프레임 워크 중에서 가장 끔찍한 느낌입니다. CSS, HTML 및 Java를 모두 혼합하는 모든 추상화 규칙을 위반합니다. JSF 프로젝트의 진행은 Spring MVC 프로젝트와 같은 ExtJS와 비교할 때 말도 안됩니다. JSF의 유지 관리는 끔찍하고 간단합니다. 그렇지 않으면 간단한 문제는 JSF의 완전한 클러스터입니다. 내 경험상 JSF를 사용하지 마십시오. 표준이든 아니든 표준이되어서는 안되는 나쁜 표준입니다. VAADIM 또는 개찰구 또는 ExtJS를 사용해보십시오.
Lawrence

1
큰 단점은 리팩토링 지원, 잘못된 웹 조각 지원, 잘못된 서버 통합, 아니요 click and go to component or include, 구성 요소 / 태그의 종속성 그래프 및 자체 또는 타사 태그 메뉴 가없는 Eclipse IDE의 평범한 통합입니다 . 구성 요소 또는 함수 x가 사용되는 위치를 이해하기 위해 프로젝트 전체 검색을 수행하는 데 많은 시간을 소비합니다.
djmj

56

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는 일부 유형의 응용 프로그램 (인트라넷, 양식 집약적)에 적합 할 수 있지만 실제 응용 프로그램에는 적합하지 않습니다.

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


4
+1 웹은 무국적이거나 좋거나 나쁘도록 설계되었으며 아무도 그것을 바꿀 수 없습니다 (그 이유는 없습니다!)
Alireza Fattahi

1
irctc.co.in은 인도에서 가장 큰 전자 상거래 사이트 인 jsf에 있습니다. . . 그러나 예 JSF를 사용하면 생성 된 UI를 많이 제어하지 못합니다.
Nirbhay Mishra

2
무엇을 정의 할 수 real-life web application있습니까? 또한 JSF는 요청 / 응답의 본질을 숨 깁니다. 사실 일 수도 있지만, 프로그래머가 실제로 적용되는 내용을 아는 것은 프로그래머의 책임입니다. HTTP의 작동 방식을 모르는 경우 JSF 또는 다른 프레임 워크 전에 HTTP를 배우십시오.
Xtreme Biker

25

떠오르는 몇 가지 단점 :

  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으로 확장하여 원하는대로 정확하게 수행 할 수 있습니다.


15
그는 JSF 1.x를 분명히 언급하고 있으며 요청 기반 MVC 프레임 워크를 염두에두고 컴포넌트 기반 MVC 프레임 워크라는 사실을 간과하고 있습니다.
BalusC

17
1) 컴포넌트 기반 MVC를 원하지 않는 경우 왜 JSF를보고 있습니까? 2) JSF 2.0 이후로는 더 이상 없습니다. 3) 도메인 부분이 사실이 아닙니다. JSF 구성 요소 중 어느 것도 그렇게하지 않습니다. impl의 JS 버그가 있습니까? Mojarra 's는 현재 매우 성숙합니다. 4) JSF는 실제로 가파른 학습 곡선이지만 반드시 그렇게 나쁘지는 않습니다. 5) 비주얼 에디터는 어쨌든 장대 한 실패입니다. 다시, 컴포넌트 기반 대 요청 기반 MVC가 중요합니다. 6) 이는 JSF가 아닌 올바른 도구의 문제입니다. Eclipse에는 플러그인이 있으며 IntelliJ Ultimate는 즉시 사용할 수 있습니다.
BalusC

19
@BalusC는 내가 무례하게 들리면 용서하지만 질문은 JSF 1 대 JSF 2가 아니며 "JSF의 역사"와 같은 대답은 관련이 없습니다. 또한 JSF에 "심각한 단점이 없다"는 귀하의 주장에 따르면 모든 도구에는 다른 솔루션을 수행하는 모든 도구에 한계와 도메인이 있다는 기본 엔지니어링 원칙이 인정되지 않습니다.
Kay Pale

24
JSF가 역사상 부정적인 영향을 미쳤던 단점이기 때문에 JSF 2.0이 어떻게 오래된 단점을 제거했는지를 배우는 데 역사가 매우 적절하다고 생각합니다. 남은 자에 관해서는, 우리는 단지 의견이 맞지 않습니다.
BalusC

5
솔직히 "구성 요소 기반"을 단점으로 나열한 이유를 이해하지 못합니다. "http의 단점은 상태가 없다는 것"입니다. 편집해야합니다. 때로는 http가 상태 비 저장 상태라는 사실이 사실이지만 때로는 우리가 그것을 사용하는 이유이기도합니다. JSF와 동일합니다.
arg20

19

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은 오늘날 소프트웨어 세계에 존재하는 것처럼 서로 결합 된 기술 중 가장 복잡하고 번거로운 혼란입니다. 그리고 나는 내가 사용하려는 것을 생각할 수 없습니다.


42
이것의 대부분은 다른 웹 프레임 워크에도 적용됩니다. 생산성을 높이기 위해 jQuery를 알아야한다는 것은 JSF의 잘못입니까?
Adrian Grigore

8
JSF는 뷰 레이어 일뿐입니다. 이제 다른 기술을 사용하면이 모든 것을 알 필요가 없다는 것을 암시하는 것처럼 보입니다.
arg20

이러한 기술은 오픈 소스이지만이를 유지 관리하는 개인 조직과 밀접한 관련이 있습니다. 아마도 독점이라는 단어는 당신에게 옳지 않지만 아마도 그럴 수도 있습니다.
AlanObject

나는 @AlanObject의 방어에오고 싶다 ... 나는 모든 오픈 소스 프로젝트가 실제로 누군가에 의해 "소유"되었다는 사실에서와 같이 독점적이라고 말했을 수도 있다고 생각한다. MySQL을 예로 들어 보자. 그들은 오라클에 매진했을 때 실제로 큰 점수를 받았습니다. 또한 Java! 따라서 오픈 소스 프로젝트는 사용 / 편집 / 기여가 가능하지만 현재 사용중인 각 오픈 소스 도구에 고유 한 사양이 적용되는 경우가 많습니다. 누군가가 "소유"했기 때문입니다. 사용하는 데 필요한 사양은 무시할 수 없습니다. 그것은 나쁜 것이 아닙니다 :)
CA Martin

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

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

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


11

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

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


11

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

내 두 센트.


그리고 각 클라이언트 측 프레임 워크는 보안, 유효성 검사 등을 위해 aerverside 대응이 필요하다는 것을 잊지 마십시오.
Kukeltje

1
물론입니다. 보안 및 유효성 검사뿐만 아니라 백엔드 및 비즈니스 논리를위한 것입니다. 모든 것은 편안한 웹 서비스를 통해 이루어집니다. 여기서 중요한 것은 서버 측에서 html을 생성하지 않는 것입니다.
Jesús López

10

우리는 JSF로 샘플 프로젝트를 개발했습니다. (3 주간의 연구 였기 때문에 몇 가지를 잃었을 수도 있습니다!)

핵심 jsf를 사용하려고합니다. 컴포넌트가 필요한 경우 PrimeFaces를 사용했습니다.

프로젝트는 탐색 기능이있는 웹 사이트였습니다. 메뉴를 클릭 할 때 각 페이지는 ajax를 통해로드되어야합니다.

이 사이트에는 두 가지 사용 사례가 있습니다.

  1. 격자가있는 페이지입니다. 그리드는 아약스를 통해로드되며 정렬 및 페이징을 지원해야합니다.
  2. 3 단계 마법사 페이지 각 페이지에는 클라이언트 측 유효성 검사 (간단한 유효성 검사)와 서버 측 아약스 기본 유효성 검사 (복잡한 유효성 검사)가 있습니다. 다음 페이지로 이동하지 않고 서비스 계층의 모든 서버 예외가 동일한 마법사 페이지에 표시되어야합니다.

우리는 그것을 발견했다 :

  1. JSF보기 상태를 수정하려면 omniFaces의 일부 해킹을 사용해야합니다. 서로에 ajax를 통해 페이지를 포함 시키면 JSF 상태가 손상됩니다. 이것은 JSF의 버그로 보이며 다음 릴리스 (2.3이 아닌)에서 수정 될 수 있습니다.
  2. JSF 플로우가 ajax에서 올바르게 작동하지 않거나 작동하지 않을 수 있습니다. 대신 Primface Wizard 구성 요소를 사용하려고 시도하지만 클라이언트 유효성 검증이 지원되지 않는 것으로 보이며 표준 JSF 플로우 표준이 아닌 동안 의미합니다.
  3. jqGird와 같은 일부 jQuery 컴포넌트를 사용하고 JSON 결과를로드해야하는 경우 순수 서블릿을 사용하는 것이 좋습니다. JSF는 사용자를 위해 아무 것도하지 않습니다. 따라서 이러한 종류의 구성 요소를 사용하면 디자인이 JSF에 적합하지 않습니다.
  4. 우리는 ajax가 완료 될 때 일부 클라이언트 스크립트를 시도 ajaxComplete하고 PF 4가 자체 ajax 이벤트를 구현 한 것을 발견했습니다. 우리는 jQuery 컴포넌트를 가지고 있었고 코드를 변경해야합니다.

위의 샘플을 Ajax 이외의 프로젝트 (또는 최소한 적은 ajax 프로젝트)로 변경하면 위의 많은 문제에 직면하지 않습니다.

우리는 우리의 연구를 다음과 같이 요약합니다 :

JSF는 완전한 아약스 기본 웹 사이트에서 잘 작동하지 않습니다.

물론 JSF에는 일부 프로젝트에 매우 유용한 유용한 기능이 많이 있으므로 프로젝트 요구 사항을 고려하십시오.

JSF의 장점을 검토하려면 JSF 기술 문서를 참조하십시오. 제 의견으로는 JSF의 가장 큰 장점은 @BalusC의 완벽하고 거대한 지원입니다.


6

저에게 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의 상황은 더 좋을 것입니다.


6

지난 몇 달 동안 Primefaces / JSF 경험에 대한 논평 :

  • "선반 외부"구성 요소를 사용할 수 있다면 끔찍하지 않은 것 같습니다.
  • 그러나 밖으로 나가서 사용자 정의 UI가 필요한 즉시 제대로 작동하지 않습니다. -예를 들어 프로젝트에 트위터 부트 스트랩을 사용해야했습니다. (머리말 부트 스트랩이 아님).
    • 이제 우리의 페이지는 다음과 같이 작동합니다.
      • 페이지로드
      • 사용자는 아약스 기능이있는 Primefaces와 상호 작용
      • 부트 스트랩의 자바 스크립트 바인딩 중단
      • 모든 것을 리 바인드하기 위해 추가 자바 스크립트를 실행합니다

자바 스크립트 작성을 피하겠다는 JSF의 약속은 Primefaces를 사용하지 않을 때보 다 더 많은 자바 스크립트를 작성하는 것으로 바뀌 었습니다.

다시 "선반에서"물건을 사용하지 않는 한 시간 싱크입니다. 또한 Selenium과 작업해야 할 때 정말 추악합니다 (Primefaces). 이 모든 것이 가능하지만 다시 한 번만 할 수 있습니다.

UX / 디자인 팀과 함께 작업하고 UI를 빠르게 반복해야하는 경우 확실히 피하십시오. jquery를 배우거나 HTML을 작성하거나 반응 / 각도를 살펴보면 시간을 절약 할 수 있습니다.


아니요, 부트 스트랩과 프라임 페이스를 선택하면 필요한 것보다 많은 자바 스크립트를 작성할 수 있습니다. 부트 페이스 또는 PF 응답 성을 사용하십시오. 그리고 어떻게 셀레늄으로 작업하는 것이 추악합니까? 정교하게 작성하십시오.
Kukeltje

여기 셀레늄 예가 있습니다. <input type="checkbox" name="versionsTab" value="version1"> HTLM 확인란 : Primefaces 확인란 : <div class="ui-chkbox ui-widget"> <div class="ui-helper-hidden-accessible"> <input type="checkbox" name="datasetForm:tabView:versionsTable_checkbox"> </div> <div class="ui-chkbox-box ui-widget ui-corner-all ui-state-default"> <span class="ui-chkbox-icon ui-c"></span> </div> </div> Selenium에서 숨겨진 실제 확인란을 찾을 수 없습니다. 예를 들어 선택기 / 코딩 / 기타로 찾을 수는 있지만 기술적 인 품질 보증팀은 할 수 없었습니다
rprasad

1
연결된 이름을 의미합니까? 아름다움은 보는 사람의 눈에 있습니다. 약간의 xpath를 배우면 많은 문제없이 우회 할 수 있습니다. 그리고 이것은 구체적으로 PF가 아닙니다. 그리고 디자인 팀에 관한 것. 템플릿을 디자인하고 나머지는 jquery-ui 지침을 준수하도록하십시오. 우리를 위해 완벽하게 일했습니다 ...
Kukeltje

나는 나중에 프로젝트에 참여했지만 부트 프레스로 시작했지만 실제로 부트 스트랩 (+ 프라임 페이스)이 필요한이 프리젠 테이션과 비슷한 문제가 발생했습니다 : oracleus.activeevents.com/2014/connect/…
rprasad

Primefaces는 어떤 방법으로도 쇼 스토퍼가 아니지만 작동하지만 여분의 시간 싱크가 있습니다. 예를 들어 Play 및 Django와 같은 프레임 워크를 사용하는 동료와 비교할 때 특히 그렇습니다. (귀하의 다른 견해에 따르면, QA는 필요한 경우 xpath를 사용할 수 있어야한다고 생각합니다. 작업 스크립트를 제공했습니다)
rprasad

1

JSF에는 많은 장점이 있습니다. 불이익에 대한 의문은 몇 가지 요점을 추가 할 수 있습니다.

일정 시간 안에 웹 프로젝트를 구현하는 실제 시나리오에서는 다음 요소를 주시해야합니다.

  • 각 시나리오에 적합한 최상의 제어 방법을 제안 할 수있는 충분한 선임 구성원이 팀에 있습니까?
  • 초기 학습 곡선을 수용 할 수있는 대역폭이 있습니까?


  • 개발자가 제작 한 JSF 자료를 검토 할 수있는 충분한 전문 지식이 팀에 있습니까?

질문에 대한 답변이 '아니요'인 경우 유지 관리 할 수없는 코드베이스가 될 수 있습니다.


0

JSF에는 한 가지 단점이 있습니다. "JSF"개발을 시작하기 전에 웹 개발, 핵심 Java 및 프론트 엔드 아키텍처를 명확하게 이해해야합니다.

요즘 "새로운"JavaScript 프레임 워크는 "JSF"컴포넌트 기반 모델을 복사 / 붙여 넣기 만하면됩니다.


0

Spring MVC, Wicket, Tapestry 등과 같은 모든 "주류"프레임 워크 중에서 복합 컴포넌트를 포함한 Java EE의 JSF는 가장 정교한 프리젠 테이션 계층 및 컴포넌트 지향 기술입니다. HybridJava가 제공하는 솔루션에 비해 약간 번거롭고 불완전합니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.