การแสดงออกของ EL ที่ซับซ้อนควรถูกแทนที่ด้วย javabean getter เดี่ยวหรือไม่?

10

ใน JSF ถ้าฉันมีองค์ประกอบที่แสดงผลตามเงื่อนไขตามจำนวนของตัวแปรวิธีที่ดีที่สุดในการจัดการกับคำสั่งแสดงผล ... ตรรกะควรอยู่ในการประกาศส่วนประกอบหรือในรูปแบบของผู้ช่วยบางรูปแบบ?

ข้อความวูฟจะปรากฏเฉพาะเมื่อสัตว์เป็นช้างหรือสุนัขและสัตว์จะไม่ถูกปิดเสียง

ตัวเลือกที่ 1:

การใช้งานในมุมมอง:

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

หรือตัวเลือก 2:

encapsulation:

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

ด้วยการใช้งาน:

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

ทั้งคู่ทำงาน ... แต่วิธีไหนที่จะจัดการสถานการณ์ได้

jsf

— TEL
แหล่งที่มา

สำหรับตัวอย่างนั้นฉันจะใช้ el ดูเหมือนว่าจะเป็นการดูข้อมูลที่เกี่ยวข้อง หากคุณมีตรรกะบางอย่างในรหัส java ของคุณbarking animalsฉันจะทำให้วิธีการที่เรียกว่าเพราะมันมีอยู่แล้ว ถ้ามันเป็นตรรกะของมุมมองที่คุณใช้กับหลาย ๆ ไซต์คุณสามารถสร้างฟังก์ชั่น el จากมันได้

การแสดงออกภาษาเดิมถูกเรียกว่าง่ายที่สุดที่เป็นไปได้การแสดงออกภาษาเพื่อที่ว่าอาจแบะท่าวัตถุประสงค์การใช้งานของมัน มุมมองของฉัน: ถ้ามันเป็นตรรกะดู EL อาจเหมาะสม ถ้ามันเป็นตรรกะทางธุรกิจมันไม่ใช่

— McDowell

5

ในกรณีส่วนใหญ่มันเป็นเพียงเรื่องของการลิ้มรส หากความกังวลของคุณเป็นเพียงการนำกลับมาใช้ซ้ำคุณสามารถทำได้

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

สิ่งนี้มักจะมีประโยชน์เมื่อนิพจน์ที่คุณต้องการเขียนเกี่ยวข้องกับวัตถุมากกว่าหนึ่งวัตถุพูดว่า:

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

ฉันคิดว่าหลายคนชอบเขียนตรรกะประเภทนี้ใน Java แทนที่จะเป็น EL เพราะคอมไพเลอร์ Java สามารถทำการตรวจสอบประเภทในโค้ด Java ได้ (เช่นกัน IDE ส่วนใหญ่มีการเติมข้อความอัตโนมัติที่ดีกว่าสำหรับ Java แล้วสำหรับไฟล์. XHTML) สำหรับบางคน.

ต้องบอกว่าถ้าเป็นข้อมูลเกี่ยวกับรูปแบบที่สักวันหนึ่งอาจถูกนำไปใช้ในที่อื่น (ไม่ใช่แค่หน้า Facelets / JSF อื่น) นั่นจะเป็นเหตุผลที่ดีที่จะทำในโค้ด Java ของคุณ ในตัวอย่างที่คุณให้วิธีการisBarkingAnimal()ให้ข้อมูลบางอย่างเกี่ยวกับรูปแบบ ( Animal) ซึ่งสักวันหนึ่งอาจเป็นประโยชน์เมื่อวัตถุอื่น (ไม่ใช่เพียงหน้า Facelets อื่น) จำเป็นต้องรู้ว่าเปลือกสัตว์ ดังนั้นฉันอาจจะไปกับที่

— อีเลียส
แหล่งที่มา

3

ตามกฎทั่วไปแล้วพยายามรักษาไฟล์. xhtml ให้ปลอดจากตรรกะมากที่สุดเท่าที่จะทำได้ดังนั้นพวกเขาจึงจัดการกับงานนำเสนอเท่านั้น ดังนั้นไปที่ตัวเลือก 2 อย่างชัดเจน

— SJuan76
แหล่งที่มา

2

มันเป็นตรรกะที่ตัวแบบจำเป็นต้องใส่ใจใช่ไหม หากมีการใช้มากกว่าหนึ่งครั้งเหตุใดการใช้นามแฝงจึงใช้<c:set>หรือ<ui:param>ไม่เป็นตัวเลือก

ตัวอย่างนั้นไม่มีตรรกะของโมเดลด้านหลัง คุณจะเปลี่ยนลอจิกดูเป็นลอจิกโมเดลซึ่งสร้างจาวาโค้ดที่ไม่ได้เรียกว่าภายในจาวา ถ้าคลาสAnimalอยู่ในสภาพแวดล้อมอื่น (รีโมต) หรือโปรแกรมเมอร์มือนั้นไม่เกี่ยวข้องกับมัน

1

ส่วนตัวฉันจะใช้ตัวเลือก # 2 ในขณะที่ฉันรู้ว่ามันเป็นไปได้ที่จะแก้ปัญหาโดยใช้ EL และรับบางส่วนของเอกสาร xhtml ที่ใช้ฟังก์ชั่นหรือ ui: params ดูเหมือนว่ามันจะขาดความสะดวกในการพกพา

หากนักพัฒนาคล่องแคล่วทั้งใน EL และ Java และเป็นเจ้าของทั้ง xhtml และ Java beans ดูเหมือนว่าจะไม่เหมาะสมที่จะใช้ EL เพื่อทำการประเมินตามเงื่อนไขด้วยขนาด> 1

ดูเหมือนว่าจะมีประโยชน์มากเกินไปสำหรับการนำไปใช้ในฝั่ง Java:

ความสามารถในการพึ่งพาคอมไพเลอร์ IDE +
ใช้ค่าคงที่หรือ enums (สำหรับ "dog" และ "bark") โอกาสที่พวกมันจะถูกใช้ที่อื่นในรหัสสำหรับการเปรียบเทียบเช่นกัน ... ถ้าค่า String เปลี่ยนไปมันสนุกจริง ๆ ที่จะต้องแทนที่ทุก ๆ ค่าของมันด้วยตัวเอง ฐานรหัส
แทนที่จะต้องไปยังหน้าเว็บที่เป็นปัญหาด้วยข้อมูลที่เหมาะสมฉันสามารถใช้ตรรกะโดยใช้การทดสอบหน่วย

หนึ่งในข้อโต้แย้งหลักที่ฉันได้ยิน (ด้านนอกของสแต็ค) ในความโปรดปรานของตัวเลือก 1 คือ:

"มันง่ายมากที่จะเห็นเมื่อส่วนประกอบแสดงผลถ้าคุณใช้ตรรกะนี้ในมุมมอง"

ฉันพบว่านี่อาจเป็นกรณีของแอปพลิเคชันในระยะแรกของชีวิตซึ่งมีน้ำหนักเบาและซับซ้อนน้อยกว่า อย่างไรก็ตามการใช้การฝึกฝนนี้ในระดับที่ใหญ่กว่าและเมื่อแอปพลิเคชั่นขนาดเล็กลงมันสามารถทำให้รังของเงื่อนไขของหนูและกลายเป็นฝันร้ายในการรักษา นี่คือตัวอย่างสองสามอย่างที่คล้ายกับสิ่งที่ฉันเห็นในป่า:

<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}"
/>

หรือรายการโปรดของฉันโดยใช้องค์ประกอบหลายรายการที่มีเงื่อนไขการแสดงผลที่ไม่เหมือนกันเพื่อแสดงค่าที่แตกต่างที่สามารถแสดงได้:

<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'}"/>

สามารถแสดงข้อความได้สูงสุด 4 ข้อความพร้อมกันหรือไม่ เมื่อมองผ่านคุณไม่สามารถบอกได้ว่าจะต้องตรวจสอบสภาพแต่ละอย่าง ในฐานะที่เป็นบันทึกด้านข้างฉันตระหนักถึงตัวอย่างนี้ก็คือการออกแบบที่ไม่ดีเช่นกันเนื่องจากสามารถใส่ได้ใน ac: เลือก ... แต่ฉันเคยเห็นสิ่งนี้มาก่อน

ในตอนท้ายของวันนี้ยังคงเป็นตรรกะ 'มุมมอง' ในทางทฤษฎีเนื่องจากมันเป็นตัวกำหนดสิ่งที่ได้รับการแสดงจริงดังนั้นจึงมีการโต้แย้งแนวคิดที่ควรมีชีวิตอยู่ใน xhtml ปัญหาที่ฉันพบคือการรวมตรรกะเช่นนี้ในเทมเพลตมุมมองสามารถทำให้เลย์เอาต์เข้าใจได้ยากขึ้นในระยะยาวและฉันยังไม่เห็นว่าวิธีการแก้ปัญหานี้มีประโยชน์ใด ๆ มากกว่าการใช้ Java การนำถั่วไปใช้

— TEL
แหล่งที่มา