JSF sao lưu cấu trúc đậu (thực hành tốt nhất)

Question

Tôi hy vọng rằng trong bài viết này, tôi có thể nhận được ý kiến ​​của mọi người về thực hành tốt nhất cho giao diện giữa các trang JSF và đậu sao lưu.

Một điều mà tôi không bao giờ có thể giải quyết là cấu trúc hạt đậu của tôi. Hơn nữa, tôi chưa bao giờ tìm thấy một bài viết hay về chủ đề này.

Thuộc tính nào thuộc về hạt sao lưu nào? Khi nào nó thích hợp để thêm nhiều thuộc tính vào một bean đã cho như trái ngược với việc tạo một bean mới và thêm các thuộc tính vào nó? Đối với các ứng dụng đơn giản, nó có ý nghĩa khi chỉ có một bean sao lưu duy nhất cho toàn bộ trang, xem xét sự phức tạp liên quan đến việc tiêm một bean vào một bean khác? Nếu đậu sao lưu có chứa bất kỳ logic kinh doanh thực tế nào, hoặc nó có nên chứa dữ liệu không?

Hãy trả lời những câu hỏi này và bất kỳ câu hỏi nào khác có thể xuất hiện.

---

Để giảm khớp nối giữa trang JSF và bean sao lưu, tôi không bao giờ cho phép trang JSF truy cập bất kỳ thuộc tính của thuộc tính bean sao lưu nào. Ví dụ, tôi không bao giờ cho phép một cái gì đó như:

<h:outputText value="#{myBean.anObject.anObjectProperty}" /> 

tôi luôn luôn đòi hỏi cái gì đó như:

<h:outputText value="#{myBean.theObjectProperty}" /> 

với một giá trị đậu ủng hộ của:

public String getTheObjectProperty() 
{ 
    return anObject.getAnObjectProperty(); 
} 

Khi tôi vòng qua một bộ sưu tập , Tôi sử dụng một lớp bao bọc để tránh đi sâu vào một đối tượng trong một bảng dữ liệu, ví dụ.

Nói chung, cách tiếp cận này cảm thấy "đúng" đối với tôi. Nó tránh bất kỳ sự kết nối nào giữa khung nhìn và dữ liệu. Nêu tôi sai vui long chân chỉnh tôi.

Answer 1

Bạn có thể muốn kiểm tra điều này: making distinctions between different kinds of JSF managed beans.

Dưới đây là một mô tả của các loại đậu khác nhau, như được định nghĩa trong bài viết ở trên bởi Neil Griffin:

• Mẫu Managed-Bean: thường phạm vi phiên. Loại bean được quản lý này tham gia vào mối quan tâm "Mô hình" của mẫu thiết kế MVC. Khi bạn thấy từ "mô hình" - hãy nghĩ DATA. Một mô hình JSF-bean phải là một POJO tuân theo mẫu thiết kế JavaBean với các thuộc tính đóng gói getters/setters. Trường hợp sử dụng phổ biến nhất cho một bean mẫu là một thực thể cơ sở dữ liệu, hoặc chỉ đơn giản là đại diện cho một tập hợp các hàng từ tập kết quả của một truy vấn cơ sở dữ liệu.
• Sao lưu Managed-Bean: Thông thường phạm vi yêu cầu. Loại bean được quản lý này tham gia vào mối quan tâm "Xem" của mẫu thiết kế MVC. Mục đích của một bean sao lưu là hỗ trợ logic UI, và có mối quan hệ 1 :: 1 với một khung nhìn JSF, hoặc một biểu mẫu JSF trong một thành phần Facelet. Mặc dù nó thường có các thuộc tính kiểu JavaBean với các getters/setters liên quan, đây là các thuộc tính của khung nhìn - không phải của mô hình dữ liệu ứng dụng cơ bản. Các bean sao lưu JSF cũng có thể có các phương thức JSF actionListener và valueChangeListener.
• Bộ điều khiển Managed-Bean: Thông thường phạm vi yêu cầu. Loại bean được quản lý này tham gia vào mối quan tâm "Bộ điều khiển" của mẫu thiết kế MVC. Mục đích của bean điều khiển là thực hiện một số loại logic nghiệp vụ và trả về một kết quả điều hướng đến trình xử lý điều hướng JSF. Các hạt điều khiển JSF thường có các phương thức hành động JSF (và không phải các phương thức actionListener).
• Hỗ trợ Managed-Bean: Thông thường phiên hoặc phạm vi ứng dụng. Loại bean này "hỗ trợ" một hoặc nhiều chế độ xem trong mối quan tâm "Chế độ xem" của mẫu thiết kế MVC. Trường hợp sử dụng điển hình là cung cấp một danh sách thả xuống ArrayList cho JSF h: selectOneMenu xuất hiện trong nhiều hơn một khung nhìn JSF. Nếu dữ liệu trong danh sách thả xuống dành riêng cho người dùng thì bean sẽ được giữ trong phạm vi phiên. Tuy nhiên, nếu dữ liệu áp dụng cho tất cả người dùng (chẳng hạn như danh sách thả xuống của các tỉnh), thì bean sẽ được giữ trong phạm vi ứng dụng, để nó có thể được lưu trữ cho tất cả người dùng.
• Tiện ích Managed-Bean: Phạm vi ứng dụng thông thường. Loại bean này cung cấp một số loại chức năng "tiện ích" cho một hoặc nhiều khung nhìn JSF.Một ví dụ tốt về điều này có thể là một bean FileUpload có thể được tái sử dụng trong nhiều ứng dụng web.

Answer 2

Tôi có thể không trả lời mọi câu hỏi của bạn, bởi vì ít có vẻ như phụ thuộc hoàn toàn vào từng trường hợp.

• Điều này là tốt để có logic nghiệp vụ trong bean sao lưu của bạn. Nó phụ thuộc vào nơi bạn đến từ. Nếu bạn đang thực hành thiết kế điều khiển miền, bạn sẽ bị cám dỗ bao gồm logic nghiệp vụ để sao lưu bean hoặc có thể là logic bền bỉ. Họ lập luận rằng tại sao đồ vật ngu ngốc như vậy. Đối tượng nên mang theo không chỉ nhà nước mà còn hành vi nữa. Mặt khác, nếu bạn xem xét cách làm việc của Java EE truyền thống, bạn có thể cảm thấy như có dữ liệu trong bean sao lưu, cũng có thể là bean thực thể của bạn, và logic kinh doanh và kiên trì khác trong bean phiên hoặc thứ gì đó. Điều đó cũng tốt.

• Hoàn toàn tốt đẹp khi có một đế sao lưu duy nhất cho toàn bộ trang. Tôi không thấy có vấn đề gì với điều này một mình. Điều này có thể không đúng, nhưng điều đó phụ thuộc vào trường hợp.

• Câu hỏi khác của bạn phụ thuộc nhiều hơn vào trường hợp bạn đang có trong tay. Tôi muốn đi tên miền được điều khiển ở đây, có thể thích hợp để thêm các thuộc tính vào hiện tại hoặc tạo ra một bean mới cho điều đó. Mà bao giờ phù hợp hơn. Tôi không nghĩ có bất kỳ viên đạn bạc nào cho việc này.

• Thuộc tính nào thuộc về bean sao lưu nào. Vâng, nó không phụ thuộc vào đối tượng miền? Hoặc có thể là câu hỏi không rõ ràng.

Hơn nữa, trong ví dụ mã đã cho, tôi không thấy bất kỳ lợi ích to lớn nào.

Answer 3

Tôi sẽ không cần thiết chỉ giữ một bean sao lưu trên mỗi trang. Nó phụ thuộc vào chức năng nhưng phần lớn thời gian tôi có một bean trên một trang vì hầu như một trang xử lý một chức năng. Ví dụ trên một trang tôi có một liên kết đăng ký (tôi sẽ liên kết với RegisterBean) và một liên kết giỏ mua hàng (ShoopingBasketBean).

Tôi sử dụng giá trị này <: outputText value = "# {myBean.anObject.anObjectProperty}" /> vì tôi thường giữ sao lưu làm bean hành động chứa đối tượng dữ liệu. Tôi không muốn viết một wrapper trong bean sao lưu của tôi để truy cập các thuộc tính của các đối tượng dữ liệu của tôi.

Answer 4

Câu hỏi hay. Tôi đã phải chịu đựng rất nhiều tình huống khó xử khi tôi chuyển sang JSF. Nó thực sự phụ thuộc vào ứng dụng của bạn. Tôi đến từ thế giới Java EE vì vậy tôi khuyên bạn nên có ít logic kinh doanh nhất trong hạt sao lưu của bạn càng tốt. Nếu logic là hoàn toàn liên quan đến việc trình bày trang của bạn, thì nó là tốt để có nó trong đậu ủng hộ.

Tôi tin rằng một trong số (nhiều) điểm mạnh của JSF thực tế là bạn có thể phơi bày các đối tượng miền trực tiếp trên các bean được quản lý. Do đó, tôi khuyên bạn nên sử dụng phương pháp <:outputText value="#{myBean.anObject.anObjectProperty}" />, nếu không bạn sẽ làm quá nhiều công việc cho chính mình khi phơi bày thủ công từng thuộc tính. Hơn nữa nó sẽ là một chút lộn xộn khi chèn hoặc cập nhật dữ liệu nếu bạn đóng gói tất cả các thuộc tính. Có những tình huống mà một đối tượng tên miền có thể không đủ. Trong những trường hợp đó, tôi chuẩn bị ValueObject trước khi phơi bày nó trên đậu.

EDIT: Trên thực tế, nếu bạn sắp đóng gói mọi thuộc tính đối tượng mà bạn muốn hiển thị, tôi khuyên bạn nên thay thế các thành phần giao diện người dùng vào bean sao lưu và sau đó tiêm nội dung trực tiếp vào giá trị của thành phần.

Về mặt cấu trúc đậu, bước ngoặt cho tôi là khi tôi bỏ qua tất cả những thứ tôi biết về xây dựng ứng dụng web và bắt đầu xử lý nó như một ứng dụng GUI thay thế. JSF bắt chước Swing rất nhiều và do đó các thực hành tốt nhất để phát triển các ứng dụng Swing sẽ chủ yếu áp dụng để xây dựng các ứng dụng JSF.

Answer 5

Tôi nghĩ rằng điều quan trọng nhất với hạt sao lưu của bạn là tách riêng các lôgic của họ. Nếu bạn có một trang bìa cho một hệ thống CMS tôi sẽ nhìn thấy nó thực tế là xấu để đặt tất cả các mảnh mã vào một đậu vì:

1. bean sẽ biến rất lớn cuối cùng
2. của nó dễ dàng hơn cho người khác tìm thấy những gì họ đang tìm kiếm nếu họ đang khắc phục sự cố trang đăng nhập, nếu họ có thể dễ dàng tìm kiếm tệp loginBean.java.
3. Đôi khi bạn có các chức năng nhỏ rõ ràng với phần còn lại của mã, bằng cách tách nó, tôi sẽ tưởng tượng bạn sẽ dễ dàng phát triển/mở rộng mã này thành một thứ lớn hơn, khi bạn đã có đậu với cấu trúc tốt.
4. Có 1 bean lớn, để làm tất cả, sẽ làm cho nó phụ thuộc vào bộ nhớ nhiều hơn nếu/khi bạn phải khai báo như thế này MyBigBean bigBean = new MyBigBean(); thay vì sử dụng funksjonality bạn thực sự cần bằng cách thực hiện LoginBean loginBean = new LoginBean(); (Đúng nếu tôi sai ở đây ???)
5. Theo tôi, tách đậu của bạn giống như tách các phương pháp của bạn. Bạn không muốn 1 phương pháp lớn chạy trên 100 dòng, nhưng thay vì chia nó với các phương thức mới để xử lý công việc cụ thể của họ.
6. Hãy nhớ, rất có thể ai đó ngoài bạn sẽ phải làm việc trên các dự án JSF của bạn.

---

Đối với khớp nối, tôi không thấy vấn đề phiền hà cho phép các trang JSF của bạn truy cập vào các thuộc tính trong đối tượng trong sao lưu của bạn. Đây là sự hỗ trợ được xây dựng trong JSF, và thực sự giúp dễ đọc và xây dựng imo hơn. Allready của bạn đã tách logic MVC một cách nghiêm túc. Bằng cách này, bạn tiết kiệm cho mình hàng tấn đường với getters và setters trong backbean của bạn. Ví dụ tôi có một đối tượng thực sự rất lớn được cung cấp cho tôi bởi các dịch vụ web, nơi tôi cần sử dụng một số thuộc tính trong bản trình bày của mình. Nếu tôi đã làm cho một getter/setter cho mỗi tài sản đậu của tôi sẽ mở rộng với ít nhất 100 dòng biến và phương pháp để nhận được propeties. Bằng cách sử dụng chức năng JSF tích hợp, thời gian và các dòng mã quý giá của tôi được tha.

Chỉ 2 xu của tôi về vấn đề này ngay cả khi câu hỏi đã được đánh dấu là đã trả lời.

Answer 6

Tôi thích kiểm tra mã doanh nghiệp không có Chế độ xem, vì vậy, tôi coi BackingBeans là giao diện từ mã Xem đến mô hình. Tôi không bao giờ đặt bất kỳ quy tắc hoặc quy trình nào trong một BackingBean. Mã đó đi vào Dịch vụ hoặc Người trợ giúp, cho phép sử dụng lại.

Nếu bạn sử dụng trình xác thực, hãy đưa chúng ra khỏi BackingBean của bạn và tham khảo chúng từ phương thức xác thực của bạn.

Nếu bạn truy cập DAO để điền Chọn, Radios, Hộp kiểm, hãy luôn thực hiện việc đó từ BackingBean.

Hãy tin tôi !. Bạn có thể tiêm một JavaBean vào một BackingBean, nhưng cố gắng tiêm một BackingBean vào một cái khác. Bạn sẽ sớm có một cơn ác mộng về mã bảo trì và hiểu biết.