Lý do KHÔNG nên sử dụng JSF [đã đóng]


64

Tôi chưa quen với StackExchange, nhưng tôi đoán bạn sẽ có thể giúp tôi.

Chúng tôi đang giới thiệu một ứng dụng Java Enterprise mới, thay thế một giải pháp JSP kế thừa. Do nhiều thay đổi, giao diện người dùng và các bộ phận của logic nghiệp vụ sẽ hoàn toàn được xem xét lại và thực hiện lại.

Suy nghĩ đầu tiên của chúng tôi là JSF, vì nó là tiêu chuẩn trong Java EE. Lúc đầu tôi có ấn tượng tốt. Nhưng bây giờ tôi đang cố gắng thực hiện một nguyên mẫu chức năng, và có một số lo ngại thực sự nghiêm trọng về việc sử dụng nó.

Trước hết, nó tạo ra hỗn hợp giả HTML / CSS / JS không hợp lệ tồi tệ nhất, lộn xộn nhất mà tôi từng thấy. Nó vi phạm mọi quy tắc duy nhất tôi học được trong phát triển web. Hơn nữa, nó kết hợp với nhau, những thứ không bao giờ nên được kết hợp chặt chẽ như vậy: Bố cục, Thiết kế, Logic và Giao tiếp với máy chủ. Tôi không thấy làm thế nào tôi có thể mở rộng đầu ra này một cách thoải mái, cho dù tạo kiểu bằng CSS, thêm kẹo UI (như các phím nóng có thể định cấu hình, các tiện ích kéo và thả) hoặc bất cứ thứ gì.

Thứ hai, nó quá phức tạp. Sự phức tạp của nó là nổi bật. Nếu bạn hỏi tôi, đó là sự trừu tượng hóa kém của các công nghệ web cơ bản, cuối cùng bị tê liệt và vô dụng. Tôi có những lợi ích gì? Không, nếu bạn nghĩ về. Hàng trăm thành phần? Tôi thấy mười nghìn đoạn mã HTML / CSS, mười nghìn đoạn mã JavaScript và hàng ngàn trình cắm jQuery bổ sung. Nó giải quyết được rất nhiều vấn đề - chúng tôi sẽ không có nếu chúng tôi không sử dụng JSF. Hoặc mẫu điều khiển phía trước cả.

Và cuối cùng, tôi nghĩ chúng ta sẽ phải bắt đầu lại từ 2 năm. Tôi không thấy cách tôi có thể triển khai tất cả các mô hình GUI đầu tiên của chúng tôi (Bên cạnh đó, chúng tôi không có Chuyên gia về JSF trong nhóm của chúng tôi). Có lẽ chúng ta có thể hack nó bằng cách nào đó. Và sau đó sẽ có nhiều hơn nữa. Tôi chắc chắn chúng tôi có thể hack hack của chúng tôi. Nhưng đến một lúc nào đó, chúng ta sẽ bị mắc kẹt. Do mọi thứ ở trên tầng dịch vụ đều nằm trong sự kiểm soát của JSF. Và chúng ta sẽ phải bắt đầu lại.

Đề xuất của tôi sẽ là triển khai api REST, sử dụng JAX-RS. Sau đó tạo ứng dụng khách HTML5 / Javascript với MVC phía máy khách. (hoặc một số hương vị của MVC ..) Nhân tiện; dù sao chúng ta cũng sẽ cần api REST, vì chúng ta cũng đang phát triển một phần Android front-end.

Tôi nghi ngờ rằng, JSF là giải pháp tốt nhất hiện nay. Khi Internet đang phát triển, tôi thực sự không hiểu tại sao chúng ta nên sử dụng 'cái cào' này.

Bây giờ, ưu / nhược điểm là gì? Làm cách nào tôi có thể nhấn mạnh quan điểm của mình để không sử dụng JSF? Điểm mạnh để sử dụng JSF so với đề xuất của tôi là gì?


24
Đó là một câu hỏi được viết tốt từ một người dùng mới. Xem xét để lại một bình luận khi downvote.
ThiefMaster

2
Vì bạn đang viết lại mọi thứ, tôi không chỉ xem xét việc không sử dụng JSF mà còn xem xét việc không sử dụng Java. Các ngôn ngữ kịch bản hiện đại ( không phải là PHP hay Perl) khá đẹp và thân thiện với nhà phát triển.
ThiefMaster

11
Tôi đã không downvote, nhưng đây không phải là một câu hỏi, nó là một câu nói hay. Vain đã quyết định rằng anh ta ghét JSF, bây giờ anh ta hỏi thêm lý do để không sử dụng nó?
Michael Borgwardt

4
Java là lựa chọn tốt nhất nếu ứng dụng của bạn sẽ lớn (phức tạp và / hoặc có thể mở rộng) và / hoặc phân phối, sử dụng nhiều dịch vụ; nếu ứng dụng của bạn không phù hợp với danh mục này (không quá phức tạp và không cần mở rộng) thì Python (Django) hoặc Ruby (Rails) sẽ là lựa chọn tốt hơn. Sự phức tạp của JSF, có những lợi ích của sức mạnh mà nó đi kèm; như là các lựa chọn thay thế, bạn nên xem các Web Framework khác như Spring MVC hoặc Struts 2 nếu Java là bắt buộc.
m3th0dman

14
Đây là một rant tìm kiếm sao lưu, không phải là một câu hỏi như vậy.

Câu trả lời:


26

Có ít nhất một lý do rất tốt để xem xét JSF.

Nó là một phần tiêu chuẩn của ngăn xếp Java EE và do đó sẽ có sẵn - và hoạt động - trong TẤT CẢ các thùng chứa Java EE trong một thời gian rất, rất dài. Và cũng được duy trì, mà bạn không cần phải làm như vậy nếu bạn đã tuân thủ nghiêm ngặt đặc tả Java EE.

Nếu đây là một mối quan tâm cho bạn, thì bạn nên xem xét nó. Hầu hết các phần mềm sống lâu hơn các nhà thiết kế của họ nghĩ, đặc biệt là nếu được xem xét khi được viết.


4
Tôi không chắc về điều đó. Đối với J2EE, các từ 'tiêu chuẩn' và 'hoạt động' không được viết bằng đá, đặc biệt khi chúng ta nói một hệ thống sẽ / sẽ được hỗ trợ trong nhiều năm, bao gồm các thay đổi đối với phiên bản j2ee được sử dụng.
magallanes

7
Theo kinh nghiệm (có giới hạn) của tôi với JSF, đối số này thực sự không giữ được. Tôi đã thấy các ứng dụng bị kẹt với một phiên bản của JSF và không có đường dẫn di chuyển lành mạnh sang phiên bản mới hơn. Chắc chắn rằng máy chủ ứng dụng vẫn thực thi nó, nhưng đó là về tất cả các hỗ trợ bạn sẽ nhận được nếu bạn không có số tiền lớn để đốt cho các hợp đồng hỗ trợ quá đắt.
Jens Schauder

@JensSchauder Kinh nghiệm của tôi chỉ là bạn có thể viết các ứng dụng di động, di chuyển và nâng cấp phiên bản jsf của chúng. Điều này liên quan đến việc biết thông số kỹ thuật và mã hóa nó, không phải để thực hiện nó. Nó hoạt động, như mã hóa cho JPA thay vì Hibernate hoạt động. Đã làm điều đó trong nhiều năm.
ymajoros

14

Bây giờ, ưu / nhược điểm là gì? Làm cách nào tôi có thể nhấn mạnh quan điểm của mình để không sử dụng JSF? Điểm mạnh để sử dụng JSF so với đề xuất của tôi là gì?

Có vẻ như bạn đã nảy sinh suy nghĩ về những nhược điểm và tôi phải làm quen với một số người trong số họ (nó không tách biệt bố cục và logic, và HTML kết quả thường rất tàn bạo), nhưng không đồng ý với người khác (nếu bạn sử dụng Facelets, mà tôi rất muốn giới thiệu, thì đầu ra chắc chắn là hợp lệ).

Vì vậy, đây là một số ưu điểm:

  • Có một số thư viện thành phần rất mạnh như PrimceFaces hoặc RichFaces cung cấp rất nhiều chức năng. Những thứ này có thể giúp bạn tiết kiệm rất nhiều công việc nếu chúng đáp ứng các yêu cầu của bạn (không quá nhiều nếu bạn có các yêu cầu không thể thương lượng không được chúng chi trả).
  • Thành phần hỗn hợp cung cấp một cách rất sạch để mô đun hóa các trang của bạn
  • JSF tích hợp rất tốt với phần còn lại của Java EE
  • AJAX thông qua kết xuất lại thành phần thực sự dễ dàng và thuận tiện

Nhưng chắc chắn không có lợi thế nào trong số những lợi thế này lớn đến mức bạn nên sử dụng JSF trên một số khung công tác khác mà nhóm của bạn đã có kinh nghiệm.


1
Đó không phải là ID, đó là thuộc tính không hợp lệ. Giống như "vai trò" và "mở rộng aria" trong chế độ xem tab. Bạn có biết làm sao để sửa cái này không?
Bruno Schäpper

1
@Vain: không, dường như là một vấn đề khác, có lẽ với một thành phần mà tôi không sử dụng hoặc là một thành phần mới. Có thể thay đổi đầu ra HTML của các thành phần JSF bằng cách chỉ định trình kết xuất thay thế (lý tưởng nhất là ghi đè một hoặc hai phương thức của trình kết xuất mặc định), nhưng tất nhiên đây không phải là điều bạn nên làm chỉ để có được đánh dấu hợp lệ.
Michael Borgwardt

1
HTML tàn bạo là do việc thực hiện được sử dụng. Theo hiểu biết của tôi thì chế độ gỡ lỗi của việc triển khai JSF tham chiếu đặc biệt tệ ở việc này. Bạn có biết các cài đặt tốt hơn để tạo HTML tốt hơn không?

1
@ Thorbjørn Ravn Andersen Vâng, vấn đề với HTML không hợp lệ thực sự là vấn đề của PrimeFaces. Chúng tôi sử dụng nó vì nó được xây dựng trên jQuery-UI. Lời khuyên của bạn là gì; Tôi có nên sử dụng một thư viện khác? Tôi thực sự thích HTML hợp lệ. Đối với tôi nó đơn giản là một PHẢI.
Bruno Schäpper

1
Xem lại câu hỏi đầu tiên của tôi ở đây, tôi muốn chia sẻ một số kinh nghiệm về ưu điểm của bạn: Chúng tôi đang làm việc với JSF và với kinh nghiệm đó, chúng tôi sẽ không chọn lại. Hầu như bất cứ điều gì hoạt động như mong đợi và ra khỏi hộp. Vâng, có Thư viện mạnh mẽ. Nhưng cuối cùng chúng tôi đã tự làm tất cả các thành phần của mình, vì chúng sẽ không hoạt động tốt như chúng tôi cần. Thật đáng kinh ngạc khi chúng tôi có 'DataTable' của riêng mình nhanh chóng với việc tải nhanh trong khi cuộn. Các thành phần hỗn hợp đã không làm việc cho chúng tôi, tôi không thể cho bạn biết lý do tại sao, chúng là lỗi tôi đoán. Kết xuất lại AJAX thực sự là một nỗi đau cho JS phía máy khách.
Bruno Schäpper

9

JSF là khung web đầy đủ trạng thái cho Java, là một tiêu chuẩn có nghĩa là nó được hỗ trợ ngoài nhiều nhà cung cấp chính (bao gồm cả các nhà cung cấp FOSS). Nó có hỗ trợ thư viện của bên thứ 3 mạnh mẽ (PrimeFaces, IceFaces, v.v.). Tuy nhiên, về cơ bản, nó 'phá vỡ web' do tính chất nhà nước của nó (và một loạt những thứ khác). Xem so sánh các khung công tác web dựa trên JVM của Matt Raible , JSF thường đi gần đến cuối cùng.

Chỉnh sửa - với JSF 2.2 - bạn có thể bắt đầu lập luận rằng nó không phá vỡ trang web nhiều như trước đây. Trên thực tế, tích hợp HTML5 không phải là tất cả khủng khiếp :-).


1
Nó 'phá vỡ mạng', thực sự .. Và cảm ơn vì sự so sánh của Matt Raible, đã không biết điều đó.
Bruno Schäpper

3
Lưu ý rằng JSF không nhất thiết phải có trạng thái. Tôi đồng ý là như vậy, nhưng có sự hỗ trợ khá tốt cho các yêu cầu dựa trên GET không trạng thái và nếu bạn không sử dụng một biểu mẫu thì sẽ không có trạng thái nào cả.
Arjan Tijms

Arjan điểm công bằng, tôi đoán tôi đã thấy nhiều cách sử dụng trạng thái.
Martijn Verburg

Liên kết đến Raible của trình bày: slideshare.net/mraible/...
zaidaus

6

Chúng tôi đã có một ứng dụng JSP / Struts 1.0 cũ. Chúng tôi đã bỏ qua Struts 2, JSF và mọi thứ khác đã xảy ra kể từ Struts 1 và nhảy vào Spring 3.0. Nó có hỗ trợ (và một cộng đồng tích cực) cho danh sách mong muốn của chúng tôi - Eclipse IDE, MVC và REST. Thêm vào đó, chúng tôi đã bỏ Javascript / ajax cổ điển của chúng tôi cho jquery.

YMMV nhưng Spring đã là một sự di chuyển trơn tru đối với chúng tôi.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.