Tại sao Qt sử dụng sai thuật ngữ mô hình / chế độ xem?

Tôi nghĩ rằng thuật ngữ được sử dụng trong Qt với các điều khiển mô hình / chế độ xem là thiếu sót. Trên trang giải thích của họ, họ nói rằng họ đã đơn giản hóa MVC thành MV bằng cách hợp nhất View và Controller và họ đưa ra hình ảnh sau:

Tuy nhiên tôi nghĩ, họ đã đặt tên sai vai trò của các đối tượng và tôi nghĩ rằng,

1. Những gì họ gọi là Chế độ xem với Bộ điều khiển hợp nhất trên thực tế chỉ là Chế độ xem.
2. Những gì họ gọi là Model trên thực tế chỉ là Controller.
3. Nếu bạn thực sự muốn có một mô hình, nó sẽ ở đâu đó nơi có "Dữ liệu" của họ.

Tôi đang nói về cách thông thường và thông thường bạn sẽ sử dụng thành phần mô hình / chế độ xem Qt trong ứng dụng của mình. Đây là những lý do:

1. Đây thường là thành phần Qt được sử dụng nguyên trạng, mà không thêm bất kỳ logic Bộ điều khiển nào cụ thể cho các đối tượng của bạn)
2. Đây hầu như không phải là Mô hình, chỉ vì bạn nên triển khai một số phương thức Qt như rowCount, columnCount, data, v.v. không liên quan gì đến mô hình của bạn. Trên thực tế, có những phương pháp mô hình điển hình được tìm thấy trong Bộ điều khiển. Tất nhiên, bạn có thể triển khai cả logic Bộ điều khiển và Mô hình ở đây, nhưng đầu tiên nó sẽ là thiết kế mã khá tệ và thứ hai bạn sẽ hợp nhất Bộ điều khiển và Mô hình chứ không phải Bộ điều khiển và Chế độ xem như chúng trạng thái.
3. Như đã nói trong lý do 2. nếu bạn muốn tách logic Mô hình thì chắc chắn đó không phải là hộp màu xanh trên hình, mà là hộp "Dữ liệu" có dấu gạch ngang (tất nhiên là giao tiếp với Dữ liệu thực).

Qt có sai trong thuật ngữ của họ không, hay chỉ có tôi là người không hiểu? (BTW: Lý do tại sao nó không phải là câu hỏi học thuật là tôi đã bắt đầu viết mã cho dự án của mình theo cách đặt tên của họ và tôi đã sớm phát hiện ra rằng mã rõ ràng là không đúng. Chỉ sau đó khi tôi nhận ra, tôi nên không thử đặt logic Mô hình trong cái mà họ gọi là Mô hình)

Tôi đồng ý với bạn rằng cách đặt tên của Qt là gây hiểu lầm. Tuy nhiên, theo ý kiến ​​của tôi, vấn đề không phải của riêng Qt mà được chia sẻ bởi tất cả các khuôn khổ cho phép chúng tôi tuân thủ nguyên tắc tách biệt các mối quan tâm khi triển khai UI của chúng tôi. Khi ai đó nghĩ ra một khuôn khổ như vậy và tìm ra cách tốt để ngăn cách "mọi thứ", họ luôn cảm thấy có nghĩa vụ phải có các mô-đun mà họ gọi là "Mô hình" và những mô-đun khác mà họ gọi là "Chế độ xem". Trong nhiều năm, tôi đã làm việc với các khuôn khổ này:

• MFC
• Qt
• Lung lay
• SWT
• WPF với MVVM

Nếu bạn so sánh cách các thuật ngữ "Model" và "View" được sử dụng trong các khuôn khổ này và trách nhiệm của các lớp trong "View", "Model" và "Controller" (nếu có), bạn sẽ thấy rằng có sự khác biệt rất lớn. Chắc chắn sẽ rất hữu ích nếu so sánh các khái niệm và thuật ngữ khác nhau, để mọi người chuyển từ khuôn khổ này sang khuôn khổ khác có cơ hội tỉnh táo, nhưng điều đó sẽ đòi hỏi rất nhiều công việc và nghiên cứu. Một bài đọc tốt là tổng quan của Martin Fowler .

Vì có rất nhiều ý kiến ​​khác nhau nên mẫu MVC có thể trông như thế nào, nên ý kiến ​​nào là đúng? Theo ý kiến ​​của tôi, những người phát minh ra MVC nên được chuyển đến khi chúng ta muốn biết nó được thực hiện như thế nào "chính xác". Trong bài báo smalltalk ban đầu, nó nói:

Dạng xem quản lý đầu ra đồ họa và / hoặc văn bản cho phần của màn hình được ánh xạ bit được phân bổ cho ứng dụng của nó. Bộ điều khiển diễn giải đầu vào chuột và bàn phím từ người dùng, ra lệnh cho mô hình và / hoặc chế độ xem thay đổi khi thích hợp. Cuối cùng, mô hình quản lý hành vi và dữ liệu của miền ứng dụng, phản hồi các yêu cầu thông tin về trạng thái của nó (thường là từ khung nhìn) và phản hồi các hướng dẫn thay đổi trạng thái (thường từ bộ điều khiển).

Vì vậy, tôi sẽ trả lời ba mối quan tâm chính của bạn:

1. Trên thực tế, một thành phần Qt "quản lý đầu ra [...] đồ họa", và "diễn giải đầu vào chuột và bàn phím", vì vậy nó thực sự có thể được gọi là Chế độ xem và Bộ điều khiển hợp nhất theo định nghĩa ở trên.
2. Tôi đồng ý rằng bạn bị / sẽ buộc phải hợp nhất Bộ điều khiển và Mô hình (một lần nữa đối với định nghĩa ở trên).
3. Tôi đồng ý, một lần nữa. Model chỉ nên quản lý dữ liệu của miền ứng dụng . Đây là những gì họ gọi là "dữ liệu". Rõ ràng, việc xử lý các hàng và cột chẳng hạn thường không liên quan gì đến miền ứng dụng của chúng tôi.

Nó để lại chúng ta ở đâu? Theo ý kiến ​​của tôi, tốt nhất là tìm hiểu Qt thực sự có nghĩa là gì khi các thuật ngữ "Model" và "View" được sử dụng và sử dụng các thuật ngữ theo cách của chúng trong khi chúng ta lập trình với Qt. Nếu bạn tiếp tục bị làm phiền, nó sẽ chỉ làm bạn chậm lại và cách mọi thứ được thiết lập trong Qt cho phép thiết kế thanh lịch - điều này làm nặng nề hơn các quy ước đặt tên "sai" của chúng.

Câu trả lời ngắn

MVC của Qt chỉ áp dụng cho một cấu trúc dữ liệu . Khi nói về một ứng dụng MVC, bạn không nên nghĩ đến QAbstractItemModelhoặc QListView.

Nếu bạn muốn có một kiến ​​trúc MVC cho toàn bộ chương trình của mình, Qt không có một khung mô hình / khung nhìn "khổng lồ" như vậy. Nhưng đối với mỗi danh sách / cây dữ liệu trong chương trình của bạn, bạn có thể sử dụng phương pháp Qt MVC thực sự có một bộ điều khiển trong chế độ xem của nó. Các dữ liệu nằm trong hoặc bên ngoài của mô hình; điều này phụ thuộc vào loại mô hình bạn đang sử dụng (lớp con của mô hình riêng: có thể nằm trong mô hình; ví dụ: QSqlTableModel: bên ngoài (nhưng có thể được lưu trong bộ nhớ cache bên trong) mô hình). Để kết hợp các mô hình và khung nhìn của bạn với nhau, hãy sử dụng các lớp riêng sau đó triển khai logic nghiệp vụ .

Câu trả lời dài

Phương pháp tiếp cận mô hình / chế độ xem và thuật ngữ của Qt:

Qt cung cấp các khung nhìn đơn giản cho các mô hình của họ. Chúng có một bộ điều khiển được tích hợp sẵn: chọn, chỉnh sửa và di chuyển các mục là thứ mà trong hầu hết các trường hợp, bộ điều khiển "điều khiển". Đó là, diễn giải đầu vào của người dùng (nhấp chuột và di chuyển) và đưa ra các lệnh thích hợp cho mô hình.

Các mô hình của Qt thực sự là các mô hình có dữ liệu cơ bản. Tất nhiên, các mô hình trừu tượng không chứa dữ liệu, vì Qt không biết bạn muốn lưu trữ chúng như thế nào. Nhưng bạn mở rộng QAbstractItemModel theo nhu cầu của mình bằng cách thêm vùng chứa dữ liệu của bạn vào lớp con và làm cho giao diện mô hình truy cập dữ liệu của bạn. Vì vậy, trên thực tế, và tôi cho rằng bạn không thích điều này, vấn đề là bạn cần lập trình mô hình, vì vậy dữ liệu được truy cập và sửa đổi như thế nào trong cấu trúc dữ liệu của bạn.

Trong thuật ngữ MVC, mô hình chứa cả dữ liệu và logic . Trong Qt, việc bạn đưa một số logic kinh doanh vào trong mô hình của mình hay đưa nó ra bên ngoài, tùy thuộc vào bạn. Thậm chí không rõ ràng logic nghĩa là gì: Chọn, đổi tên và di chuyển các mục? => đã được thực hiện. Làm phép tính với chúng? => Đặt nó bên ngoài hoặc bên trong lớp con của mô hình. Lưu trữ hoặc tải dữ liệu từ / vào một tệp? => Đặt nó bên trong lớp con của mô hình.

Quan điểm cá nhân của tôi:

Rất khó để cung cấp một hệ thống MV (C) tốt và chung chung cho một lập trình viên. Bởi vì trong hầu hết các trường hợp, các mô hình là đơn giản (ví dụ: chỉ có danh sách chuỗi) Qt cũng cung cấp một QStringListModel sẵn sàng sử dụng. Nhưng nếu dữ liệu của bạn phức tạp hơn chuỗi, bạn muốn thể hiện dữ liệu như thế nào qua giao diện xem / mô hình Qt. Ví dụ: nếu bạn có một cấu trúc có 3 trường (giả sử những người có tên, tuổi và giới tính), bạn có thể gán 3 trường cho 3 cột khác nhau hoặc cho 3 vai trò khác nhau. Tôi không thích cả hai cách tiếp cận.

Tôi nghĩ rằng khung mô hình / khung nhìn của Qt chỉ hữu ích khi bạn muốn hiển thị các cấu trúc dữ liệu đơn giản . Sẽ khó xử lý nếu dữ liệu thuộc loại tùy chỉnh hoặc có cấu trúc không nằm trong cây hoặc danh sách (ví dụ: biểu đồ). Trong hầu hết các trường hợp, danh sách là đủ và thậm chí trong một số trường hợp, một mô hình chỉ nên chứa một mục nhập duy nhất. Đặc biệt nếu bạn muốn lập mô hình một mục nhập duy nhất có các thuộc tính khác nhau (một thể hiện của một lớp), thì khung mô hình / khung nhìn của Qt không phải là cách phù hợp để tách logic khỏi giao diện người dùng.

Tóm lại, tôi nghĩ rằng mô hình / khung xem của Qt hữu ích nếu và chỉ khi dữ liệu của bạn đang được xem bởi một trong các tiện ích người xem của Qt . Hoàn toàn vô ích nếu bạn sắp viết trình xem của riêng mình cho một mô hình chỉ chứa một mục nhập, ví dụ như cài đặt ứng dụng của bạn hoặc nếu dữ liệu của bạn không thuộc loại có thể in được.

Tôi đã sử dụng mô hình / chế độ xem Qt trong một ứng dụng (lớn hơn) như thế nào?

Tôi đã từng viết (trong một nhóm) một ứng dụng sử dụng nhiều mô hình Qt để quản lý dữ liệu. Chúng tôi quyết định tạo một DataRoleđể giữ dữ liệu thực tế thuộc loại tùy chỉnh khác nhau cho từng lớp con của mô hình khác nhau. Chúng tôi đã tạo một lớp mô hình bên ngoài được gọi là Modelgiữ tất cả các mô hình Qt khác nhau. Chúng tôi cũng tạo một lớp khung nhìn bên ngoài được gọi là Viewgiữ các cửa sổ (widget) được kết nối với các mô hình bên trong Model. Vì vậy, cách tiếp cận này là một Qt MVC mở rộng, được điều chỉnh cho phù hợp với nhu cầu của chúng ta. Bản thân cả hai Modelvà Viewcác lớp không liên quan gì đến Qt MVC.

Chúng ta đã đặt logic ở đâu? Chúng tôi đã tạo các lớp thực hiện tính toán thực tế trên dữ liệu bằng cách đọc dữ liệu từ các mô hình nguồn (khi chúng thay đổi) và ghi kết quả vào các mô hình đích. Theo quan điểm của Qt, các lớp logic này sẽ là các khung nhìn, vì chúng "kết nối" với các mô hình (không phải "chế độ xem" cho người dùng, mà là một "chế độ xem" cho phần logic nghiệp vụ của ứng dụng).

Bộ điều khiển ở đâu? Trong thuật ngữ MVC ban đầu, bộ điều khiển diễn giải đầu vào của người dùng (chuột và bàn phím) và đưa ra các lệnh cho mô hình để thực hiện hành động được yêu cầu. Vì chế độ xem Qt đã diễn giải thông tin đầu vào của người dùng như đổi tên và di chuyển các mục, điều này không cần thiết. Nhưng những gì chúng tôi cần là diễn giải về tương tác của người dùng vượt ra ngoài quan điểm Qt.

Thuật ngữ này không đúng hay sai, nó hữu ích hay vô dụng.

Bạn có thể thay đổi câu hỏi một chút và hỏi tại sao Qt không thân thiện với MVC hơn. Câu trả lời là các nhà phát triển Qt ban đầu tin rằng việc tách V khỏi C trong các ứng dụng GUI sẽ khiến cả V và C không tốt. Thiết kế của QWidget cố gắng làm cho nó trở nên đơn giản để gắn kết quá trình nhập chuột chặt chẽ với các quyết định đầu ra pixel và bạn có thể thấy đó không phải là con đường hướng tới MVC.

Như mẫu chức năng là để đáp ứng với yêu cầu cung cấp thông tin, tôi nghĩ rằng không có gì là sai trong việc xác định các phương pháp như rowCount, columnCount, vv Tôi nghĩ rằng Mẫu là một số loại wrapper cho nguồn dữ liệu (cho dù nó là gì bảng SQL hoặc chỉ là một mảng) , nó cung cấp dữ liệu ở dạng chuẩn và bạn nên xác định các phương pháp phụ thuộc vào cấu trúc nguồn dữ liệu của bạn.

Tôi tin rằng thuật ngữ của họ là đúng ... mặc dù trong các ứng dụng thực tế, tôi thấy có thể rất dễ làm mờ ranh giới giữa mô hình, chế độ xem và bộ điều khiển tùy thuộc vào mức độ trừu tượng của bạn: chế độ xem của một cấp có thể là mô hình của cấp cao hơn.

Tôi cảm thấy sự nhầm lẫn nảy sinh từ lớp QAbstractModelItem của họ. Lớp này không phải là một mục mô hình, mà nó là một giao diện cho một mô hình. Để làm cho các lớp xem của họ giao diện với mô hình, họ phải tạo một giao diện trừu tượng chung cho mô hình. Tuy nhiên, một mô hình có thể là một mục duy nhất, một danh sách các mục, một bảng gồm 2 hoặc nhiều kích thước của các mục, v.v.; vì vậy giao diện của họ phải hỗ trợ tất cả các biến thể mô hình này. Phải thừa nhận rằng điều này làm cho các mục mô hình khá phức tạp và mã keo để làm cho nó hoạt động với một mô hình thực tế dường như kéo dài ẩn dụ một chút.

Tôi nghĩ rằng ... Những gì họ gọi là Model trên thực tế chỉ là Controller.

Không, "mô hình" của họ chắc chắn không phải là bộ điều khiển.

Bộ điều khiển là một phần của các điều khiển hiển thị của người dùng để sửa đổi mô hình (và do đó gián tiếp sửa đổi chế độ xem). Ví dụ, một nút "xóa" là một phần của bộ điều khiển.

Tôi nghĩ rằng thường có sự nhầm lẫn vì nhiều người nhìn thấy một cái gì đó như "bộ điều khiển sửa đổi mô hình" và nghĩ rằng điều này có nghĩa là các hàm thay đổi trên mô hình của họ, giống như phương thức "deleteRow ()". Nhưng trong MVC cổ điển, bộ điều khiển cụ thể là phần giao diện người dùng. Các phương thức làm thay đổi mô hình chỉ đơn giản là một phần của mô hình.

Kể từ khi MVC được phát minh, sự phân biệt giữa bộ điều khiển và chế độ xem ngày càng trở nên căng thẳng. Hãy nghĩ về một hộp văn bản: nó vừa hiển thị cho bạn một số văn bản vừa cho phép bạn chỉnh sửa nó, vậy nó là view hay controller? Câu trả lời phải là nó là một phần của cả hai. Trở lại khi bạn làm việc trên một chiếc teletype vào những năm 1960, sự khác biệt rõ ràng hơn - hãy nghĩ đến ed- nhưng điều đó không có nghĩa là mọi thứ tốt hơn cho người dùng vào thời điểm đó!

Đúng là QAbstractItemModel của họ là cấp độ cao hơn so với một mô hình thông thường. Ví dụ: các mục trong đó có thể có màu nền (về mặt kỹ thuật là bút vẽ), đây là một thuộc tính quan trọng nhất định! Vì vậy, có một lập luận rằng QAbstractItemModel giống một chế độ xem hơn và dữ liệu của bạn là mô hình. Sự thật là nó nằm ở đâu đó giữa các ý nghĩa cổ điển của khung nhìn và mô hình. Nhưng tôi không thể thấy nó là một bộ điều khiển như thế nào; nếu bất cứ thứ gì đó là widget QT sử dụng nó.