ทำไม Qt จึงใช้คำศัพท์เกี่ยวกับโมเดล / มุมมองในทางที่ผิด?

ฉันคิดว่าคำศัพท์ที่ใช้ใน Qt กับ model / view controls นั้นมีข้อบกพร่อง ในหน้าคำอธิบายพวกเขาระบุว่าพวกเขาทำให้ MVC เป็น MV ง่ายขึ้นโดยการรวม View และ Controller และให้ภาพต่อไปนี้:

อย่างไรก็ตามฉันคิดว่าพวกเขาตั้งชื่อบทบาทของวัตถุผิดและฉันคิดว่า

1. สิ่งที่พวกเขาเรียกว่า View with merged Controller นั้นเป็น View only
2. สิ่งที่พวกเขาเรียกว่า Model คือตัวควบคุมเท่านั้น
3. หากคุณต้องการมีโมเดลจริงๆก็น่าจะเป็นที่ "ข้อมูล" ของพวกเขา

ฉันกำลังพูดถึงวิธีปกติและมีเหตุผลที่คุณจะใช้องค์ประกอบ Qt model / view ในแอปของคุณ นี่คือเหตุผล:

1. โดยทั่วไปจะเป็นคอมโพเนนต์ Qt ซึ่งใช้ตามที่เป็นอยู่โดยไม่ต้องเพิ่มลอจิกคอนโทรลเลอร์เฉพาะสำหรับอ็อบเจ็กต์ของคุณ)
2. นี่ไม่ใช่ Model เพียงเพราะคุณควรใช้วิธีการ Qt หลายอย่างเช่น rowCount, columnCount, data เป็นต้นซึ่งไม่มีส่วนเกี่ยวข้องกับโมเดลของคุณ ในความเป็นจริงมีวิธีแบบจำลองทั่วไปที่พบในคอนโทรลเลอร์ แน่นอนคุณสามารถใช้ทั้ง Controller และ Model logic ได้ที่นี่ แต่ก่อนอื่นมันจะเป็นการออกแบบโค้ดที่ค่อนข้างแย่และประการที่สองคุณจะรวม Controller และ Model ไม่ใช่ Controller และ View ตามที่ระบุ
3. ตามที่กล่าวไว้ในเหตุผล 2. ถ้าคุณต้องการแยก Model logic ว่ามันไม่ใช่กล่องสีน้ำเงินบนรูปภาพอย่างแน่นอน แต่เป็นช่อง "Data" ที่เป็นเส้นประ (แน่นอนว่าสื่อสารกับข้อมูลจริง)

Qt ผิดในคำศัพท์ของพวกเขาหรือเป็นเพียงฉันที่ไม่เข้าใจ? (BTW: เหตุผลที่มันไม่ใช่คำถามเชิงวิชาการคือฉันได้เริ่มเขียนโค้ดโปรเจ็กต์ของฉันหลังจากการตั้งชื่อของพวกเขาและในไม่ช้าฉันก็พบว่าโค้ดนั้นไม่ถูกต้องหลังจากนั้นก็ต่อเมื่อฉันรู้ว่าฉันควรจะ อย่าพยายามใส่ Model logic ในสิ่งที่พวกเขาเรียกว่า Model)

ฉันเห็นด้วยกับคุณว่าการตั้งชื่อของ Qt ทำให้เข้าใจผิด อย่างไรก็ตามในความคิดของฉันปัญหาไม่ได้อยู่ที่ Qt เพียงอย่างเดียว แต่ถูกแบ่งปันโดยกรอบงานทั้งหมดที่ช่วยให้เรายึดมั่นในหลักการแยกข้อกังวลเมื่อใช้ UI ของเรา เมื่อมีคนใช้กรอบดังกล่าวและพบวิธีที่ดีในการแยก "สิ่งต่างๆ" ออกจากกันพวกเขามักจะรู้สึกว่าจำเป็นต้องมีโมดูลที่เรียกว่า "Model" และอื่น ๆ ที่เรียกว่า "View" ในช่วงหลายปีที่ผ่านมาฉันทำงานกับกรอบเหล่านี้:

• MFC
• Qt
• แกว่ง
• สวท
• WPF กับ MVVM

หากคุณเปรียบเทียบการใช้คำว่า "Model" และ "View" ในเฟรมเวิร์กเหล่านี้และความรับผิดชอบของคลาสใน "View", "Model" และ "Controller" (ถ้ามี) คุณจะ พบว่ามีความแตกต่างที่ยิ่งใหญ่มาก การเปรียบเทียบแนวคิดและคำศัพท์ที่แตกต่างกันจะเป็นประโยชน์อย่างแน่นอนเพื่อให้ผู้คนที่เปลี่ยนจากกรอบงานหนึ่งไปยังอีกกรอบหนึ่งมีโอกาสที่จะมีสติ แต่จะต้องใช้งานและการวิจัยเป็นจำนวนมาก อ่านที่ดีคือมาร์ตินฟาวเลอร์ของภาพรวม

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

มุมมองจะจัดการเอาต์พุตกราฟิกและ / หรือข้อความไปยังส่วนของการแสดงผลแบบบิตแมปที่จัดสรรให้กับแอ็พพลิเคชัน ตัวควบคุมตีความอินพุตของเมาส์และคีย์บอร์ดจากผู้ใช้สั่งให้โมเดลและ / หรือมุมมองเปลี่ยนไปตามความเหมาะสม สุดท้ายแบบจำลองจะจัดการพฤติกรรมและข้อมูลของโดเมนแอปพลิเคชันตอบสนองต่อคำร้องขอข้อมูลเกี่ยวกับสถานะ (โดยปกติจะมาจากมุมมอง) และตอบสนองต่อคำแนะนำในการเปลี่ยนสถานะ (โดยปกติจะมาจากคอนโทรลเลอร์)

ในแง่นี้ฉันจะตอบข้อกังวลหลักสามประการของคุณด้วยเหตุนี้:

1. ในความเป็นจริงคอมโพเนนต์ Qt "จัดการเอาต์พุต [... ] แบบกราฟิก" และ "ตีความอินพุตของเมาส์และคีย์บอร์ด" ดังนั้นจึงอาจเรียกได้ว่าเป็น View and Controller ที่ผสานเข้าด้วยกันตามคำจำกัดความข้างต้น
2. ฉันยอมรับว่าคุณ / ถูกบังคับให้รวม Controller และ Model (อีกครั้งตามคำจำกัดความข้างต้น)
3. ฉันเห็นด้วยอีกครั้ง รุ่นควรจัดการข้อมูลของโดเมนโปรแกรมประยุกต์ นี่คือสิ่งที่พวกเขาเรียกว่า "ข้อมูล" เห็นได้ชัดว่าการจัดการกับแถวและคอลัมน์เช่นโดยปกติแล้วไม่มีอะไรเกี่ยวข้องกับโดเมนแอปพลิเคชันของเรา

มันทิ้งเราไปไหน? ในความคิดของฉันเป็นการดีที่สุดที่จะเข้าใจว่า Qt หมายถึงอะไรเมื่อมีการใช้คำว่า "Model" และ "View" และใช้คำศัพท์ในลักษณะเดียวกันในขณะที่เรากำลังเขียนโปรแกรมด้วย Qt หากคุณใส่ใจอยู่เรื่อย ๆ มันจะทำให้คุณช้าลงเท่านั้นและวิธีการตั้งค่าสิ่งต่างๆใน Qt ทำให้มีการออกแบบที่หรูหราซึ่งมีน้ำหนักมากกว่าหลักการตั้งชื่อที่ "ผิด"

คำตอบสั้น ๆ

MVC ของ Qt ใช้กับโครงสร้างข้อมูลเดียวเท่านั้น เมื่อพูดถึง MVC แอพลิเคชันที่คุณไม่ควรคิดเกี่ยวกับหรือQAbstractItemModelQListView

หากคุณต้องการสถาปัตยกรรม MVC สำหรับโปรแกรมทั้งหมดของคุณ Qt ไม่มีโมเดล / มุมมอง "ขนาดใหญ่" แต่สำหรับแต่ละรายการ / โครงสร้างข้อมูลในโปรแกรมของคุณคุณสามารถใช้แนวทาง Qt MVC ซึ่งมีตัวควบคุมอยู่ในมุมมองของมัน ข้อมูลที่อยู่ภายในหรือภายนอกของรูปแบบ; ขึ้นอยู่กับประเภทของโมเดลที่คุณใช้ (คลาสย่อยของโมเดลของตัวเอง: อาจจะอยู่ในโมเดลเช่น QSqlTableModel: ภายนอก (แต่อาจถูกแคชไว้ภายใน) โมเดล) ที่จะนำรูปแบบและมุมมองของคุณร่วมกันใช้คลาสของตัวเองซึ่งก็ใช้ตรรกะทางธุรกิจ

คำตอบยาว

รูปแบบ / แนวทางการดูและคำศัพท์ของ Qt:

Qt ให้มุมมองที่เรียบง่ายสำหรับโมเดลของพวกเขา พวกเขามีตัวควบคุมในตัว: การเลือกแก้ไขและย้ายรายการเป็นสิ่งที่โดยส่วนใหญ่แล้วคอนโทรลเลอร์ "ควบคุม" นั่นคือการตีความอินพุตของผู้ใช้ (การคลิกและย้ายเมาส์) และให้คำสั่งที่เหมาะสมกับโมเดล

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

ใน MVC ศัพท์รูปแบบมีทั้งข้อมูลและตรรกะ ใน Qt นั้นขึ้นอยู่กับคุณว่าคุณจะรวมตรรกะทางธุรกิจบางอย่างไว้ในโมเดลของคุณหรือไม่หรือวางไว้ภายนอกโดยเป็น "มุมมอง" ในตัวของมันเอง ยังไม่ชัดเจนว่าตรรกะหมายถึงอะไร: การเลือกเปลี่ยนชื่อและย้ายรายการไปรอบ ๆ ? => ดำเนินการแล้ว ทำการคำนวณกับพวกเขาหรือไม่? => วางไว้ด้านนอกหรือด้านในคลาสย่อยของโมเดล การจัดเก็บหรือโหลดข้อมูลจาก / ไปยังไฟล์? => ใส่ไว้ในคลาสย่อยของโมเดล

ความคิดเห็นส่วนตัวของฉัน:

เป็นเรื่องยากมากที่จะจัดหาระบบMV (C) ที่ดีและทั่วไปให้กับโปรแกรมเมอร์ เนื่องจากในกรณีส่วนใหญ่โมเดลนั้นเรียบง่าย (เช่นเฉพาะรายการสตริง) Qt ยังมี QStringListModel ที่พร้อมใช้งาน แต่ถ้าข้อมูลของคุณซับซ้อนกว่าสตริงขึ้นอยู่กับว่าคุณต้องการแสดงข้อมูลผ่านอินเทอร์เฟซ Qt model / view อย่างไร ตัวอย่างเช่นหากคุณมีโครงสร้างที่มี 3 ฟิลด์ (สมมติว่าบุคคลที่มีชื่ออายุและเพศ) คุณสามารถกำหนด 3 ฟิลด์ให้กับ 3 คอลัมน์ที่แตกต่างกันหรือ 3 บทบาทที่แตกต่างกัน ฉันไม่ชอบทั้งสองวิธี

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

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

ฉันใช้ Qt model / view ภายในแอปพลิเคชัน (ใหญ่กว่า) ได้อย่างไร

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

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

ตัวควบคุมอยู่ที่ไหน? ในคำศัพท์ MVC ดั้งเดิมคอนโทรลเลอร์จะตีความอินพุตของผู้ใช้ (เมาส์และคีย์บอร์ด) และให้คำสั่งกับโมเดลเพื่อดำเนินการตามที่ร้องขอ เนื่องจากมุมมอง Qt ตีความอินพุตของผู้ใช้เช่นการเปลี่ยนชื่อและย้ายรายการจึงไม่จำเป็น แต่สิ่งที่เราต้องการคือการตีความการโต้ตอบของผู้ใช้ซึ่งนอกเหนือไปจากมุมมอง Qt

คำศัพท์ไม่ถูกหรือผิดมีประโยชน์หรือไม่มีประโยชน์

คุณอาจเปลี่ยนคำถามเล็กน้อยและถามว่าทำไม Qt ถึงไม่เหมาะกับ MVC คำตอบคือนักพัฒนา Qt รุ่นแรก ๆ เชื่อว่าการแยก V จาก C ในแอปพลิเคชัน GUI นั้นทำให้ Vs และ Cs ไม่ดีทั้งคู่ การออกแบบของ QWidget พยายามทำให้ง่ายต่อการเชื่อมโยงการป้อนข้อมูลของเมาส์อย่างใกล้ชิดกับการตัดสินใจเอาต์พุตพิกเซลและคุณจะเห็นได้ว่านั่นไม่ใช่เส้นทางสู่ MVC

ในฐานะที่เป็นรุ่นฟังก์ชั่นคือการตอบสนองต่อการร้องขอสำหรับข้อมูลที่ผมคิดว่ามีอะไรผิดปกติในการกำหนดวิธีการเช่นrowCount, columnCountฯลฯ ผมคิดว่ารุ่นเป็นชนิดของเสื้อคลุมสำหรับแหล่งที่มาข้อมูลบางส่วน (ไม่ว่ามันคืออะไรตาราง SQL หรือเพียงแค่อาร์เรย์) ให้ข้อมูลในรูปแบบมาตรฐานและคุณควรกำหนดวิธีการขึ้นอยู่กับโครงสร้างแหล่งข้อมูลของคุณ

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

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

ฉันคิดว่า ... สิ่งที่พวกเขาเรียกว่า Model นั้นแท้จริงแล้วคือ Controller เท่านั้น

ไม่ "แบบจำลอง" ของพวกเขาไม่ใช่ตัวควบคุมอย่างแน่นอน

คอนโทรลเลอร์เป็นส่วนหนึ่งของการควบคุมที่ผู้ใช้มองเห็นได้ซึ่งปรับเปลี่ยนโมเดล (ดังนั้นจึงปรับเปลี่ยนมุมมองโดยอ้อม) ตัวอย่างเช่นปุ่ม "ลบ" เป็นส่วนหนึ่งของตัวควบคุม

ฉันคิดว่ามักจะมีความสับสนเพราะหลายคนเห็นบางอย่างเช่น "คอนโทรลเลอร์ปรับเปลี่ยนโมเดล" และคิดว่านี่หมายถึงฟังก์ชันการกลายพันธุ์ในโมเดลของพวกเขาเช่นเมธอด "deleteRow ()" แต่ใน MVC แบบคลาสสิกคอนโทรลเลอร์เป็นส่วนติดต่อผู้ใช้โดยเฉพาะ วิธีการที่ทำให้โมเดลกลายพันธุ์เป็นเพียงส่วนหนึ่งของโมเดล

นับตั้งแต่ MVC ถูกคิดค้นขึ้นความแตกต่างระหว่างคอนโทรลเลอร์และมุมมองก็ตึงเครียดมากขึ้นเรื่อย ๆ ลองนึกถึงกล่องข้อความ: ทั้งสองแสดงข้อความและให้คุณแก้ไขได้ดังนั้นจึงเป็นมุมมองหรือตัวควบคุม? คำตอบจะต้องเป็นส่วนหนึ่งของทั้งสองอย่าง ย้อนกลับไปเมื่อคุณทำงานกับโทรพิมพ์ในปี 1960 ความแตกต่างชัดเจนขึ้น - ลองนึกถึงed- แต่นั่นไม่ได้หมายความว่าสิ่งต่างๆจะดีกว่าสำหรับผู้ใช้ในตอนนั้น!

เป็นความจริงที่ว่า QAbstractItemModel ของพวกเขาค่อนข้างสูงกว่าแบบจำลองปกติ ตัวอย่างเช่นรายการในนั้นอาจมีสีพื้นหลัง (ในทางเทคนิคแปรง) ซึ่งเป็นแอตทริบิวต์ view-ish ที่เด็ดเดี่ยว! ดังนั้นจึงมีข้อโต้แย้งว่า QAbstractItemModel เป็นเหมือนมุมมองมากกว่าและข้อมูลของคุณคือโมเดล ความจริงก็คือมันอยู่ที่ไหนสักแห่งระหว่างความหมายคลาสสิกของมุมมองและโมเดล แต่ฉันมองไม่เห็นว่ามันเป็นคอนโทรลเลอร์ได้อย่างไร หากมีสิ่งใดที่เป็นวิดเจ็ต QT ที่ใช้