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


104

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

ภาพอธิบาย Qt MVC

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

  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)


1
MFC กำหนดมาตรฐานสำหรับรุ่น 2 ส่วน / ดู guis ด้วย CDoc และ CView - ไม่มีเหตุผลใดที่ MVC นั้น 'ถูกต้อง'
Martin Beckett

@Martin B: ฉันจะดู MFC แม้ว่าจะมีโมเดล MVC ที่แตกต่างกันฉันคิดว่ามันควรจะสอดคล้องกับคำศัพท์ของพวกเขาและฉันคิดว่าฉันได้นำเสนอข้อโต้แย้งที่ถูกต้องแล้วทำไมคำศัพท์ที่ใช้จึงไม่สอดคล้องกันในกรณีนี้ พวกเขาเพียงแค่ระบุว่าพวกเขาได้รวม View และ Controller ไว้ด้วยกัน แต่ฉันคิดว่ามันเป็นเพียงการเข้าใจผิดธรรมดาในกรณีนี้ ฉันไม่คิดว่าจะมีโมเดล MVC ที่ตรรกะเฉพาะของแอปพลิเคชันทั้งหมดไม่ว่าจะเป็นการนำเสนอหรือตรรกะของโมเดลจะต้องใส่ไว้ในวัตถุเดียวที่เรียกว่า Model
gorn

1
@Martin B: นอกจากนี้ภายใต้คำศัพท์ qt ทุกรุ่นมี api ทั่วไปซึ่งไม่มีส่วนเกี่ยวข้องกับโครงสร้างโมเดล แต่ทุกอย่างเกี่ยวข้องกับโครงสร้างคอนโทรลเลอร์ทั่วไปซึ่งเป็นสัญญาณอย่างชัดเจนว่าไม่ถูกต้องที่จะเรียกว่า Model ฉันไม่ได้บอกว่ามีโมเดล MVC ที่ถูกต้องหนึ่งแบบ แต่ก็ไม่ได้หมายความว่าจะเรียกว่าโมเดล MVC ได้มากกว่าสิ่งใด อาจจะมีข้อบกพร่องใน MFC เช่นกันและฉันสามารถดูได้ แต่ฉันสนใจ Qt มากกว่าทำให้ถูกต้อง MFC ที่ฉันไม่ได้ตั้งใจจะใช้ คุณมีลิงค์ที่ดีที่อธิบายการแยกแบบจำลอง / มุมมอง MFC หรือไม่?
gorn

1
คำศัพท์ MVC ไม่ได้มีการตกลงกันเป็นเอกฉันท์ดังนั้นคำถามของคุณจึงถือได้ว่าเป็นการโต้แย้ง อย่างไรก็ตามหลายคนจะเห็นด้วยกับผลงานที่ยอดเยี่ยมของ Martin Fowler ( martinfowler.com/eaaDev/index.html ) โดยปกติคอนโทรลเลอร์จะจัดการอินพุตของผู้ใช้และในแง่นี้วิดเจ็ต Qt มักจะรวมมุมมองและคอนโทรลเลอร์เข้าด้วยกัน
Arnold Spence

1
ฉันเข้าใจว่า MVC มีหลายรสชาติ แต่ก็ไม่ได้หมายความว่าอะไรจะเป็น MVC ได้ Qt ล้ำเส้นและฉันให้เหตุผลหลายประการ Martin Fowler อธิบาย MVC ประเภทต่างๆ แต่ไม่มีทั้งสองแบบที่คล้ายคลึงกันเพียงพอกับสิ่งที่ Qt ออกเสียง MVC สิ่งที่คล้ายกันมากที่สุดคือmartinfowler.com/eaaDev/PresentationModel.htmlแต่สิ่งนี้แยกความแตกต่างระหว่างส่วน Presentation Model = Controller (การโต้ตอบกับผู้ใช้) และ Model (ตรรกะข้อมูล) ดังนั้นแม้ว่าจะไม่มีคำจำกัดความที่ชัดเจนของ MVC แต่ Qt ก็ไม่ได้เป็นไปตามใด ๆ หากคุณสามารถให้ลิงก์ไปยังคำจำกัดความดังกล่าวได้โปรดดำเนินการดังกล่าว
gorn

คำตอบ:


78

ฉันเห็นด้วยกับคุณว่าการตั้งชื่อของ 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 ทำให้มีการออกแบบที่หรูหราซึ่งมีน้ำหนักมากกว่าหลักการตั้งชื่อที่ "ผิด"


2
ฉันจะบอกว่าผู้รับมอบสิทธิ์เป็นผู้ควบคุมของ Qt เนื่องจากผู้รับมอบสิทธิ์รับและส่งอินพุตไปยังโมเดลซึ่งอัปเดตมุมมองผ่านสัญญาณ
Peregring-lk

83

คำตอบสั้น ๆ

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 Model ที่แตกต่างกันโดยสิ้นเชิงขึ้นอยู่กับมุมมองที่คุณต้องการ แบบจำลองสำหรับมุมมองรายการจะไม่สนับสนุนมุมมองแบบต้นไม้อย่างเหมาะสมและในทางกลับกัน โมเดล MVC ที่เป็นที่ยอมรับสามารถรองรับมุมมองประเภทต่างๆมากมายเหลือเฟือ
smerlin

3
@smerlin: ฉันไม่คิดว่าถูกต้อง ทั้ง QListView และ QTreeView ต้องการเฉพาะอินเทอร์เฟซ QAbstractItemView ซึ่งหมายความว่าคลาสย่อยที่กำหนดเองหรือคลาสคอนกรีตเช่น QStandardItemModel ควรเติมเต็มข้อกำหนดนั้นสำหรับทั้งสองอย่าง คุณสามารถขับต้นไม้และแสดงรายการแบบจำลองหนึ่งรุ่นได้
jdi

1
@jdi: มีหลายกรณีที่ข้อมูลของคุณเป็นทั้งรายการและทรี ... เช่นคุณอาจต้องการแสดงระบบไฟล์ของคุณเป็นแบบต้นไม้หรือไฟล์ทั้งหมดเป็นรายการ โมเดล Qts ไม่อนุญาตอย่างถูกต้อง การใช้ QAbstractItemModel ที่สนับสนุนมุมมองแบบทรีอนุญาตให้แสดงไฟล์ / ไดเร็กทอรีทั้งหมดในไดเร็กทอรีรากของคุณเป็นรายการเท่านั้น แต่คุณไม่สามารถแสดงไฟล์ทั้งหมดเป็นรายการได้ และอย่าบอกว่าการแสดงข้อมูลต้นไม้เป็นรายการไม่สามารถมีประโยชน์ได้ ตัวอย่างเช่นคุณสามารถจัดเรียงไฟล์เพื่อค้นหาไฟล์ที่มีขนาดไฟล์ที่ใหญ่ที่สุดได้อย่างง่ายดายหากคุณแสดงไฟล์ของคุณเป็นรายการมุมมองแบบต้นไม้จะไม่อนุญาตให้ทำเช่นนั้น
smerlin

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

1
@SamPinkus นั่นเป็นเพราะคำถามนี้ไม่ชัดเจนใช่หรือไม่ใช่ นอกจากนี้ยังมีการใช้งานที่แตกต่างกันQAbstractItemModelซึ่งบางส่วนเป็นแบบจำลองในแง่ของ MVC และบางส่วนก็ไม่ใช่
leemes

12

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

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


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

ฉันไม่สามารถพูดอะไรได้เลยว่าทำไมเอกสาร Qt ถึงพูดถึง MVC ในแบบที่พวกเขาทำ ฉันออกจาก Trolltech ไปนานแล้วและรู้สึกงงงวยกับบางสิ่งที่ทำกับเอกสารตั้งแต่ฉันจากไป (ในบล็อกของฉันฉันไม่บางครั้งพูดจาโผงผางเล็กน้อยเกี่ยวกับที่แม้ว่า.)
arnt

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

เราไม่ได้ใช้คำว่า "MVC" ในเอกสาร Qt ในช่วงเวลาที่ฉันอยู่ที่ Trolltech โดยทั่วไปฉันคิดว่าดีที่สุดที่จะบันทึกสิ่งที่อยู่ในนั้นไม่ใช่เขียนเกี่ยวกับสิ่งที่ไม่มีอยู่ อย่างไรก็ตามในช่วงบนgitoriousคุณสามารถหาที่เพิ่มข้อความที่และเพิ่มบุคคลนั้นโดยตรง
arnt

1
ความคิดเห็นที่แตกต่าง เราได้พูดคุยเกี่ยวกับ MVC ในระหว่างการออกแบบและวลีการใช้งานช่วงแรกของ Qt (เมื่อ Trollech เป็น บริษัท สามคน) และเราประเมินชุดเครื่องมือ GUI ที่ใช้ MVC "อย่างถูกต้อง" ฉันจำชื่อไม่ได้ ความเห็นของเราคือชุดเครื่องมือนั้นใช้งานได้แย่มากและ MVC ก็มีเหตุผลมาก
arnt

3

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


2

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

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


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

0

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

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

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

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

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

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

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.