JavaFX - วิธีที่เหมาะสมในการใช้คุณสมบัติกับวัตถุโดเมน

10

JavaFX ได้จัดทำวัตถุออบเจ็กต์ใหม่จำนวนมากเช่นjavafx.beans.property.DoublePropertyที่อนุญาตให้คุณกำหนดฟิลด์ที่สามารถสังเกตและซิงโครไนซ์ได้โดยอัตโนมัติ

ในตัวอย่าง JFX หลายรุ่นคลาส MVC มีจำนวนฟิลด์คุณสมบัติเหล่านี้ซึ่งสามารถผูกเข้ากับมุมมองโดยอัตโนมัติ

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

มีใครเคยเห็นปัญหานี้ได้รับการแก้ไขใน 'ชีวิตจริง' และถ้าเป็นเช่นนั้นมันทำอย่างไร?

properties javafx domain-objects

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

โปรดแก้ไขให้ฉันถ้าฉันผิด แต่ความเข้าใจเกี่ยวกับ JavaFX ของฉันก็คือมันถูกระงับโดย Sun ในปี 2008 ก่อนที่จะซื้อ Oracle และเพิ่งได้รับการตกแต่งใหม่สู่ตลาดด้วยการลดลงของ Silverlight และ Decline of Flash บนอุปกรณ์ Apple บางทีคุณอาจถูกต้องว่าเป็นคู่กับมุมมองอย่างแน่นหนาและเหตุผลดั้งเดิมที่ถูกระงับไว้ที่ดวงอาทิตย์ แค่ความคิด

— Jack Stone

ซันและตอนนี้ออราเคิลทำงานอย่างต่อเนื่องกับ JavaFX มาหลายปีแล้ว การเปลี่ยนแปลงครั้งสำคัญเมื่อไม่นานมานี้คือการหยุดภาษาการเขียนโปรแกรม "JavaFX Script" ซึ่งจำเป็นต้องใช้ JavaFX และเพื่อสลับไปใช้ Java ทั่วไป การเปลี่ยนแปลงนี้เกิดจากการยอมรับที่ไม่ดีและค่าใช้จ่ายในการสนับสนุนภาษาการเขียนโปรแกรมใหม่ทั้งหมด

— Stuart Marks

4

ฉันได้เล่นกับ JavaFX 2.0 ซึ่งฉันคิดว่าคำถามของคุณเกี่ยวกับ ไม่ใช่รหัสการผลิตจริงเป็นเพียงโครงการส่วนตัว แต่ฉันพบปัญหาเดียวกันกับที่คุณพูดถึงข้างต้น แบบจำลองทั้งหมดมีแนวโน้มที่จะขึ้นอยู่กับกรอบ 2D และฉันไม่ชอบมัน

สิ่งที่ฉันทำคือฉันแยกทุก ๆ คลาสในโมเดลเป็นสองคลาสโมเดลจริงซึ่งมีความสามารถในการโหลดเนื้อหาจากฐานข้อมูลรู้วิธีที่จะเปลี่ยนแปลงสถานะ ฯลฯ ฯลฯ ... และคลาสตัวแทนที่ตัดสินใจลักษณะที่ปรากฏ บนหน้าจอ. หลังจะมีคลาสคุณสมบัติทั้งหมด

คุณจะพบการออกแบบเดียวกันในกรอบ MVC ใด ๆ เช่น Swing เป็นเพียงแค่ที่นี่ไม่มีทางหนีจากการทำมัน

— Hannes R.
แหล่งที่มา

กรอบที่บังคับให้คุณใช้หลักการออกแบบที่ดีหรือระเบิดใบหน้าของคุณถ้าคุณไม่ ในฐานะที่เป็น. NET สิ่งนี้เป็นสิ่งที่ฉันคุ้นเคยอย่างมาก

— MattDavey

0

เกือบ 7 ปีต่อมาและคำถามนี้ยังคงใช้ได้เหมือนเดิม

ในความคิดของฉัน javafx ไม่ควรนำเข้าโดยคลาสใด ๆ ที่เป็นของ Model อย่างไรก็ตามมันอาจทำงานได้ดีถ้าคุณใช้ MVVM ร่วมกับสถาปัตยกรรม MVC ในแง่นี้

เอนทิตี = (โดเมน) โมเดล ( M )
ไฟล์ FXML = มุมมอง ( V )
คอนโทรลเลอร์ยังคงเป็นคอนโทรลเลอร์ ( C )
the view-model ( VM ) = ชุดของคลาสข้อมูลใหม่ที่มีคุณสมบัติ javafx เท่านั้นและการอ้างอิงไปยังวัตถุโดเมนจริง (M) ที่แสดง มันอาจผ่านวิธีการทางตรรกะทางธุรกิจเรียกเพิ่มเติมเพื่อวัตถุนี้ทำหน้าที่เป็นคอมโพสิต / มัณฑนากร

อีกวิธีหนึ่งในการมองสิ่งต่าง ๆ คือการคิดว่าคลาสคอนโทรลเลอร์เป็นส่วนหนึ่งของมุมมองเนื่องจากทั้งหมดนี้คือการผูกโมเดลมุมมองเข้ากับมุมมอง (ข้อมูลและการกระทำ) ดังนั้นจึงสามารถเรียกได้อย่างง่ายดายว่าผู้นำเสนอหรือแม้แต่ Binder ขึ้นอยู่กับว่าคุณใช้คอนโทรลเลอร์อย่างไร ถ้าคุณเพิ่มตรรกะสำหรับจัดการรูปแบบมุมมองในคลาสตัวควบคุมมันควรได้รับชื่อและคุณมีสถาปัตยกรรมที่นำเสนอข้างต้น หากคลาสคอนโทรลเลอร์เชื่อมโยงข้อมูลโมเดลกับองค์ประกอบ UI และ ActionEvents กับวิธีการจำลองเท่านั้นคุณมักจะมีสถาปัตยกรรมกลายพันธุ์ MVVM ที่แสดงด้านล่าง

ฉันคิดว่าสถาปัตยกรรมเหล่านี้ตรงกับความคิดของลุงบ็อบเกี่ยวกับสถาปัตยกรรมที่สะอาด (เลเยอร์การนำเสนอ)

— Vlad Călin Buzea
แหล่งที่มา