JSF를 사용하지 않는 이유 [닫기]

나는 StackExchange를 처음 사용하지만 도움이 될 것이라고 생각했다.

레거시 JSP 솔루션을 대체하여 새로운 Java Enterprise 애플리케이션을 작성하고 있습니다. 많은 변경으로 인해 UI와 비즈니스 로직의 일부가 완전히 다시 생각되고 구현 될 것입니다.

우리의 첫 생각은 Java EE의 표준이기 때문에 JSF였습니다. 처음에는 좋은 인상을 받았습니다. 그러나 지금은 기능적 프로토 타입을 구현하려고하는데 사용에 대해 심각한 우려가 있습니다.

우선, 내가 본 것 중 최악의 가장 복잡한 잘못된 의사 HTML / CSS / JS 믹스를 만듭니다. 그것은 웹 개발에서 배운 모든 규칙을 위반합니다. 또한 레이아웃, 디자인, 논리 및 서버와의 통신과 같이 긴밀하게 결합되어서는 안되는 요소가 함께 제공됩니다. CSS로 스타일링하거나 UI 캔디 (구성 가능한 핫키, 드래그 앤 드롭 위젯 등) 추가 또는 기타로이 출력을 어떻게 편안하게 확장 할 수 있을지 모르겠습니다.

둘째, 너무 복잡합니다. 복잡성이 뛰어납니다. 당신이 저에게 묻는다면, 그것은 기본 웹 기술의 불완전한 추상화입니다. 어떤 혜택이 있습니까? 당신이 생각한다면 수백 개의 구성 요소? 수천 개의 HTML / CSS 스 니펫, 수천 개의 JavaScript 스 니펫 및 수천 개의 jQuery 플러그인도 볼 수 있습니다. 실제로 많은 문제를 해결합니다. JSF를 사용하지 않으면 없을 것입니다. 또는 전면 컨트롤러 패턴.

마지막으로 2 년 후에 다시 시작해야한다고 생각합니다. 첫 번째 GUI 모형을 모두 구현할 수있는 방법을 모릅니다 (단, 팀에는 JSF 전문가가 없습니다). 어쩌면 우리는 어떻게 든 그것을 해킹 할 수 있습니다. 그리고 더있을 것입니다. 우리 해킹을 해킹 할 수 있다고 확신합니다. 그러나 어느 시점에서 우리는 갇힐 것입니다. 서비스 계층 위의 모든 것이 JSF를 제어합니다. 그리고 우리는 다시 시작해야 할 것입니다.

JAX-RS를 사용하여 REST API를 구현하는 것이 좋습니다. 그런 다음 클라이언트 측 MVC를 사용하여 HTML5 / Javascript 클라이언트를 작성하십시오. (또는 일부 MVC의 맛.) 그런데; 우리는 부분적으로 안드로이드 프론트 엔드를 개발하고 있기 때문에 어쨌든 REST API가 필요합니다.

JSF가 오늘날 최고의 솔루션이라는 것은 의심의 여지가 있습니다. 인터넷이 발전함에 따라 우리가 왜이 '레이크'를 사용해야하는지 알 수 없습니다.

이제 장단점은 무엇입니까? JSF를 사용하지 않겠다는 요점을 어떻게 강조 할 수 있습니까? 내 제안에 JSF를 사용하는 장점은 무엇입니까?

JSF를 고려해야 할 이유는 적어도 하나 이상 있습니다.

그것은 자바 EE 스택의 표준이며, 따라서 사용할 수 있습니다 - 그리고 작업 아주, 아주 긴 시간 동안 모든 Java EE 컨테이너에 -. Java EE 스펙을 엄격하게 준수한 경우에도 그렇게하지 않아도됩니다.

이것이 당신에게 관심이 있다면, 당신은 그것을 고려해야합니다. 대부분의 소프트웨어는 디자이너가 생각하는 것보다 오래 산다.

이제 장단점은 무엇입니까? JSF를 사용하지 않겠다는 요점을 어떻게 강조 할 수 있습니까? 내 제안에 JSF를 사용하는 장점은 무엇입니까?

당신은 이미 단점에 대해 생각한 것처럼 보이며, 나는 그들 중 일부와 인사를 나눠야합니다 (배치와 논리를 충분히 분리하지 못하고 결과 HTML은 종종 끔찍합니다). 내가 매우 권장하는 Facelets, 출력은 확실히 유효해야합니다).

여기 몇 가지 장점이 있습니다.

• PrimceFaces 또는 RichFaces와 같은 매우 강력한 구성 요소 라이브러리가있어 많은 기능을 즉시 제공합니다. 요구 사항을 충족시키는 경우 많은 작업을 절약 할 수 있습니다 (협상 할 수없는 요구 사항이있는 경우에는 그다지 중요하지 않음).
• 복합 컴포넌트는 페이지를 모듈화하는 매우 깨끗한 방법을 제공합니다
• JSF는 나머지 Java EE와 매우 잘 통합됩니다.
• 컴포넌트 재 렌더링을 통한 AJAX는 정말 쉽고 편리합니다.

그러나 확실히 이러한 장점 중 어느 것도 너무 커서 팀이 이미 경험 한 다른 프레임 워크보다 JSF를 사용해야합니다.

JSF는 Java를위한 적절한 상태 저장 웹 프레임 워크로서 표준이며 이는 많은 주요 공급 업체 (FOSS 포함)에서 즉시 지원합니다. 타사 라이브러리 지원이 강력합니다 (PrimeFaces, IceFaces 등). 그러나 상태가 좋은 특성 (및 기타 여러 가지)으로 인해 기본적으로 웹을 중단합니다. Matt Raible의 JVM 기반 웹 프레임 워크 비교를 참조하십시오 . JSF는 대개 마지막에 가깝습니다.

JSF 2.2를 사용하여 편집-웹이 한 번처럼 끊어지지 않는다고 주장하기 시작할 수 있습니다. 실제로 HTML5 통합이 끔찍한 것은 아닙니다 :-).

레거시 JSP / Struts 1.0 애플리케이션이있었습니다. Struts 2, JSF 및 Struts 1 이후 발생한 모든 것을 건너 뛰고 Spring 3.0으로 뛰어 들었습니다. 우리의 위시리스트-Eclipse IDE, MVC 및 REST에 대한 지원 및 활성 커뮤니티가 있습니다. 또한 우리는 jquery를 위해 빈티지 자체 Javascript / ajax를 버렸습니다.

YMMV이지만 Spring은 우리에게 원활한 마이그레이션이었습니다.