Có bất kỳ bất lợi nào đối với SEAM không?

Question

Là một nhà phát triển ứng dụng web java, tôi đã sử dụng JSF (SUN) năm ngoái cho một khung công tác cho các ứng dụng web của tôi. Tôi phải nói rằng tôi rất thích sử dụng nó, nó làm cho việc phát triển dễ dàng hơn.

Gần đây, tôi đã đọc rất nhiều điều tốt về JBoss Seam, nhưng tôi vẫn chưa gặp phải một người đã sử dụng nó. Từ những gì tôi đã đọc, có vẻ như SEAM là bước tiếp theo của JSF.

Câu hỏi của tôi là do đó, đối với bạn đã sử dụng SEAM: trong khi bạn làm việc với công nghệ này, bạn có gặp bất kỳ khó khăn nào không? Bạn có nói nó cảm thấy tự nhiên khi bạn làm việc với nó?

Answer 1

Lợi thế của bất kỳ khuôn khổ nào như SEAM hoặc Grails là mức trừu tượng cao hơn. Nó sẽ chăm sóc các chi tiết cơ bản cho bạn và, nếu nó được thiết kế và viết tốt, làm cho mọi thứ dễ dàng hơn.

Những bất lợi của bất kỳ khung như SEAM hoặc Grails là nó ẩn rất nhiều chi tiết từ bạn. Nếu bạn không bao giờ tìm hiểu những gì đang xảy ra bên dưới, bạn có thể tìm thấy chính mình trong một thế giới của rắc rối nếu bạn gặp khó khăn và không biết bất cứ điều gì về mã được tạo ra cho bạn.

Một bất lợi khác là các giả định mà họ xây dựng vào mô hình có thể không phải lúc nào cũng như những gì bạn muốn. Nhưng việc thay đổi chúng có nghĩa là phá vỡ con đường mà họ đã đặt ra cho bạn, điều đó không dễ dàng.

Lời khuyên của tôi là sử dụng khung và đánh giá cao những lợi ích mà nó mang lại, nhưng không sử dụng chúng như một cái cớ để ngừng tìm hiểu những gì đang xảy ra bên dưới. Là người có thể viết toàn bộ mọi thứ bằng tay, không có khuôn khổ, nhưng chọn sử dụng nó cho đòn bẩy mà nó cung cấp.

Answer 2

Tôi cảm thấy tự nhiên đối với tôi và việc sử dụng chú thích giúp cuộc sống trở nên dễ dàng hơn. Tôi thậm chí không thể tưởng tượng làm việc với khung getAttribute/getParameter. Một bất lợi là seam-gen không hoạt động với Maven (nhưng Seam3 sẽ dựa trên Maven). Tôi nghĩ rằng Seam làm cho bạn tập trung vào những gì bạn muốn đạt được và với các khuôn khổ khác, bạn phải suy nghĩ làm thế nào để làm điều đó. Bạn đã bao giờ thử làm Ajax với javascript/prototype/jquery chưa? Nó thực sự đau đớn so với nút Ajax đường may với lời gọi phương thức và những gì để reRender. Javascript là thực sự không cần thiết ở tất cả với đường may và Rich Faces. đối với tôi đó là khuôn khổ tốt nhất mà tôi đã sử dụng.

Answer 3

Không đúng khi nói "Đường may là bước tiếp theo của JSF". Seam không phải sử dụng JSF làm lớp xem. Nó cũng có thể sử dụng Wicket hoặc GWT.

Tuy nhiên khi được sử dụng với JSF, công việc tuyệt vời là đơn giản hóa nó. Bạn có ít cấu hình XML hơn JSF chuẩn và tôi thường quên rằng JSF không có những thứ như ngữ cảnh hội thoại hoặc các cuộc gọi phương thức tham số trong EL. ví dụ:

<h:commandButton action="#{myBean.sayHello('damo')}" value="hello"/> 

Thật dễ dàng để làm việc và khả năng sử dụng POJO ở mọi nơi rất tự do.Đó là nhược điểm lớn nhất là những liên quan đến JSF:

• Quá nhiều sự phụ thuộc vào HTTP POST (mà s:button/link không phải lúc nào giải quyết)
• Rất nhiều javascript
• cuộc gọi quá mức để Getters/setters
• Nasty tìm kiếm HTML; vv

Hiện có hơn trang đủ chi tiết những thiếu sót của JSF elsewhere (lưu ý rằng đây không phải là những lời chỉ trích của Seam - chứ không phải của JSF1.x và nhiều người đang giải quyết trong JSF2.0)

tôi don Không tin rằng Seam là "bước tiếp theo" cho JSF nhưng nó và Facelets là rất quan trọng nếu bạn dự định sử dụng JSF1.x ngay bây giờ.

Tôi nghĩ rằng JSF2.0 và WebBeans là bước tiếp theo.

Answer 4

Tôi thích JSF và tôi đã đánh giá Seam cách đây không lâu. JSF là một khuôn khổ giao diện người dùng web, trong khi Seam là một khung ứng dụng web tổng quát hơn, tích hợp không chỉ JSF mà còn là ngữ cảnh đàm thoại, luồng công việc (jBPM) và sự kiên trì đối tượng (tốt nhất là EJB3). Lần đầu tiên tôi được thu hút bởi Seam bởi giàn giáo được tạo tự động được quảng cáo, nhưng tôi chưa bao giờ làm cho nó hoạt động với mô hình dữ liệu doanh nghiệp của mình. Kể từ đó, tôi đã quan tâm nhiều hơn đến Spring Framework và Spring JSF. Nó hấp dẫn với tôi như là mô-đun hơn và nếu bạn sử dụng iBATIS nó chỉ cần một thùng chứa servlet như Tomcat, không phải là một thùng chứa Java EE như JBoss. Mùa xuân đã được xung quanh lâu hơn và có mindshare lớn hơn.

ICEfaces cũng rất tuyệt vời với JSF và facelets, nó hoạt động hoàn toàn tốt với hoặc không có khung ứng dụng như Seam hoặc Spring.

Answer 5

Tôi đã sử dụng Seam trong một dự án lớn đang diễn ra với IceFaces. Seam chắc chắn là tốt hơn nhiều so với sử dụng đồng bằng JSF (tham khảo các liên kết được đăng bởi Damo một vài câu trả lời ở trên).

Tuy nhiên, một số vấn đề tôi nhớ: thử nghiệm

• đơn vị: nhận SeamTest để làm việc đúng cách đặc biệt là trong một tích hợp xây dựng liên tục là khó khăn, tìm kiếm trên web cho "vấn đề SeamTest". Ngoài ra, hãy xem điều này: Has anyone successfully run integration tests with Jboss embedded, Seam and Maven?
• Nhiều cách để nhà phát triển thực hiện mọi việc và không phải quá nhiều thực tiễn tốt nhất được ghi lại. Vì vậy, bạn phải dành nhiều thời gian và tìm ra điều gì là tốt nhất cho nhóm dự án của bạn.Ví dụ, khi thực hiện các hình thức, đây là các thẻ tiềm năng (lưu ý rằng một số trong số họ chồng chéo):

Facelets < ui: repeat >

JSTL < c: forEach >

JSF < h : hình thức >

ICEfaces < băng: selectOneMenu >

JSF < f: selectitems >

Seam < s: nút >

• hiệu suất là nghi ngờ, đặc biệt là với IceFaces, here is a related article Ngoài ra, bạn cần "mức guru" kiến ​​thức về Seam để làm Ngay Thing, cách mặc định khiến bạn gặp rắc rối. Xem bài viết này để biết chi tiết: Speed up your Data-Driven JSF/Seam Application by Two Orders of Magnitude - Part 1
• vì Seam 3 sắp xảy ra và phải sử dụng 2 thông số mới (JSF 2 và WebBeans) để lại các câu hỏi về những gì xảy ra với dự án trên Seam 2 và mất bao lâu để ổn định đường cong học tập
• . IMHO đường may cố gắng làm quá nhiều, cung cấp cho bạn wrappers trên những thứ như iText, Quartz, JExcel, jBPM, vv Và hội nhập Seam với khuôn khổ bên thứ ba dự kiến ​​là một bước phía sau các phiên bản mới nhất. Ví dụ, chúng tôi đã tích hợp jBPM trực tiếp bởi vì chúng tôi cần một số tính năng mới nhất.
• có thể do thiếu truy vấn tiêu chí trong JPA 1.X, cách bạn triển khai màn hình tìm kiếm động (nơi người dùng điền vào nhiều tùy chọn bộ lọc và bạn phải tạo HQL động) cảm thấy rất thanh lịch và là khi sử dụng lớp EntityQuery "Seam Application Framework" được đề xuất, hãy xem liên kết dưới đây để biết ví dụ đơn giản, nhưng bạn có thể biết ý tưởng về tiêu chí lọc phức tạp, xử lý giá trị rỗng, thứ tự và tất cả: How can I to order an EntityQuery query in a seam app?

Answer 6

Đường nối, như một khung tích hợp, thực sự sẽ cho thấy tính hữu ích của nó khi được ghép nối với các khung công tác khác mà bạn muốn sử dụng.

Nếu bạn sắp sử dụng EJB và JSF, SEAM là kẻ giết người.

Nếu bạn định sử dụng JSF (cộng với bất kỳ công cụ liên quan nào của nó, như IceFaces hoặc RichFaces) SEAM POJO có thể đơn giản hóa quá trình thiết lập của bạn cũng như cung cấp cho bạn quyền truy cập cuộc trò chuyện, v.v.)

Nếu bạn đang sử dụng EJB với Wicket hoặc GWT, Seam có thể tiết kiệm cho bạn một số cấu hình, tuy nhiên, tôi chưa đích thân sử dụng cấu hình này.

Như đã nói, nhược điểm của Seam là cố hữu trong bất kỳ khung trừu tượng nào: Nó ẩn chi tiết của bạn. Nếu nó bắt đầu bị rò rỉ, bạn đang gặp rắc rối. Tôi chưa có nó rò rỉ cho tôi nhưng tôi cũng dành thời gian để cho bản thân mình một sự hiểu biết cơ bản về cách thức hoạt động của nó. Làm thế nào EL làm việc với các chú thích Seam và như vậy.

Có hay không bạn sẽ tìm thấy đường nối hữu ích phụ thuộc vào khuôn khổ bạn sẽ sử dụng nó. Seam chắc chắn có vị trí ngọt ngào nhưng điểm đó đang phát triển. Seam chắc chắn không phải là một dự án đã chết.:)

Answer 7

Nếu bạn đặt logger vào thành phần Seam (ví dụ: resultList), bạn sẽ thấy Seam gọi cùng một phương thức nhiều lần. Đây là những lời chỉ gây phiền nhiễu duy nhất về Seam. Nhưng Seam chắc chắn "cố định" JSF là khá sai lầm của chính nó. Cho phép xem JSF2. Bất kể những vấn đề đó, tôi rất vui khi sử dụng Seam.

Answer 8

Bạn luôn có thể sử dụng Factory annotation để tránh các cuộc gọi đến cùng một phương thức lặp đi lặp lại. Nhà máy cho phép các thành phần được cập nhật.