Có nên thay thế một biểu thức EL phức tạp bằng một getter javabean không?

Trong JSF nếu tôi có một thành phần kết xuất có điều kiện dựa trên một số biến thì cách tối ưu để xử lý câu lệnh kết xuất ... logic có nên tồn tại trong khai báo thành phần hoặc trong một dạng lớp của trình trợ giúp không?

Việc giả mạo văn bản chỉ được hiển thị khi một con vật là voi hoặc chó và con vật không bị câm.

Lựa chọn 1:

Thực hiện theo quan điểm:

<h:outputText id="text" value="woof" 
  rendered="#{animal.type == 'elephant' 
                  or animal.type == 'dog' and not(animal.mute)}"/>

hoặc lựa chọn 2:

Đóng gói:

<h:outputText id="text" value="woof" rendered="#{animal.barkingAnimal}"/>

với việc thực hiện:

public class Animal {
     public boolean isBarkingAnimal() {
         return ("dog".equals(getType()) || "elephant".equals(getType())) && !isMute();
     }
...

Vì vậy, cả hai đều hoạt động ... nhưng đó là cách đúng đắn để xử lý tình huống?

Trong hầu hết các trường hợp, nó chỉ đơn giản là một vấn đề của hương vị. Nếu mối quan tâm của bạn chỉ đơn giản là sử dụng lại điều kiện, bạn cũng có thể làm:

<ui:param name="animalCanBark" value="#{animal.type == 'elephant' 
              or animal.type == 'dog' and not(animal.mute)}" />
...
<h:outputText id="text" value="woof" rendered="#{animalCanBark}"/>

Điều này thường hữu ích khi biểu thức bạn cần viết không chỉ liên quan đến một đối tượng, nói:

<ui:param name="showBarking" value="#{animal.type == 'elephant'
              and not facesContext.validationFailed" />

Tôi nghĩ rằng nhiều người thích viết loại logic này bằng Java thay vì trong EL vì trình biên dịch Java có thể thực hiện kiểm tra kiểu trong mã Java (ngoài ra, hầu hết các IDE có tự động hoàn thành tốt hơn cho Java sau đó cho các tệp .XHTML), đó là một vấn đề đáng lo ngại cho một số

Phải nói rằng, nếu đó là thông tin về mô hình mà một ngày nào đó có thể được sử dụng ở một nơi khác (không chỉ trang Facelets / JSF khác), thì đó sẽ là lý do chính đáng để thực hiện nó trong mã Java của bạn. Trong ví dụ bạn đã đưa ra, phương thức này isBarkingAnimal()cung cấp một số thông tin về mô hình ( Animal), một ngày nào đó cuối cùng có thể hữu ích khi một đối tượng khác (không chỉ là trang Facelets khác) cần biết nếu một con vật nào đó sủa. Vì vậy, tôi có thể sẽ đi với điều đó.

Theo nguyên tắc thông thường, hãy cố gắng giữ các tệp .xhtml không có logic nhất có thể để chúng chỉ xử lý khi trình bày. Vì vậy, rõ ràng đi cho tùy chọn 2.

Cá nhân, tôi sẽ sử dụng Tùy chọn # 2. Mặc dù tôi biết rằng rất có thể giải quyết vấn đề bằng EL và có được một chút sử dụng lại trên các tài liệu xhtml bằng các hàm hoặc ui: params dường như thực sự thiếu tính di động, khả năng duy trì và khả năng kiểm tra của việc triển khai Java bean.

Nếu một nhà phát triển thông thạo cả EL và Java và sở hữu cả hai hạt xhtml và Java, thì dường như không có ý nghĩa gì khi sử dụng EL để thực hiện bất kỳ đánh giá có điều kiện nào với kích thước> 1.

Dường như có quá nhiều lợi ích khi triển khai ở phía Java:

• Khả năng dựa vào trình biên dịch IDE +
• Sử dụng các hằng hoặc enum (cho "dog" và "bark"), rất có thể chúng đang được sử dụng ở nơi khác trong mã để so sánh ... nếu giá trị String thay đổi, thật vui khi phải thay thế thủ công mọi thứ trên nó cơ sở mã
• Thay vì phải điều hướng đến trang được đề cập với dữ liệu phù hợp, tôi có thể thực hiện logic bằng các bài kiểm tra đơn vị

Một trong những đối số chính mà tôi đã nghe (bên ngoài Stack) có lợi cho Tùy chọn 1 là:

"Sẽ dễ dàng hơn nhiều khi nhìn thấy một thành phần biểu hiện nếu bạn giữ logic này trong chế độ xem."

Tôi đã thấy rằng đây có thể là trường hợp của một ứng dụng trong giai đoạn đầu của cuộc sống khi nó có trọng lượng nhẹ hơn và ít phức tạp hơn. Tuy nhiên, áp dụng thực hành này ở quy mô lớn hơn và khi một ứng dụng nhỏ hơn đáo hạn, nó có thể khiến một tổ chuột có điều kiện và trở thành một cơn ác mộng để duy trì. Dưới đây là một vài ví dụ tương tự như những gì tôi đã thấy ngoài tự nhiên:

<h:outputText value="grrr" 
    render="#{animal.type == 'dog' or animal.type == 'cat' or animal.type == 'horse' 
        or animal.type == 'pony' or animal.type == 'mule' or animal.type == 'lion'
        or animal.type == 'tiger' or (animal.type == 'bird' 
        and animal.subType == 'macaw') or .... continue this for another line or two}"
/>

Hoặc sở thích của tôi, sử dụng nhiều thành phần có điều kiện kết xuất không thuộc về nhau để thể hiện các giá trị khác nhau có thể được hiển thị:

<h:outputText value="grr" render="#{theMonstrosityFromPreviousExample} />
<h:outputText value="cry" 
    render="#{animal.type == 'human' and animal.subType == 'baby'}" />
<h:outputText value="yo" 
    render="#{animal.type == 'human' and animal.subType == 'teenager'}" />
<h:outputText value="hello" 
    render="#{animal.type == 'human' and animal.subType == 'adult'}"/>

Có thể hiển thị tối đa 4 văn bản cùng một lúc? Thoạt nhìn bạn không thể biết, việc kiểm tra từng điều kiện sẽ là cần thiết. Như một lưu ý phụ tôi nhận ra ví dụ này cũng là thiết kế kém, vì chúng có thể được đặt trong ac: select ... nhưng tôi đã thấy điều này trước đây.

Vào cuối ngày, đây vẫn là logic 'xem' về mặt lý thuyết vì nó xác định những gì thực sự được hiển thị để có một đối số khái niệm nên tồn tại trong xhtml. Vấn đề mà tôi đã tìm thấy là việc bao gồm logic như thế này trong mẫu khung nhìn có thể khiến bố cục khó hiểu hơn về lâu dài và tôi vẫn chưa thấy rằng phương pháp giải quyết vấn đề này mang lại bất kỳ lợi ích thực sự nào khi sử dụng Java đậu thực hiện.