Qtがモデル/ビューの用語を誤用しているのはなぜですか？

Qtでモデル/ビューコントロールを使用して使用されている用語には欠陥があると思います。上の彼らの説明ページ彼らはビューとコントローラをマージして、彼らは以下の画像を与えていることにより、MVにMVCを簡素化することを、状態：

しかし、私は彼らがオブジェクトの役割を誤って名付けたと思います。

1. マージされたコントローラーでビューと呼ばれるものは、実際にはビューのみです。
2. 彼らがモデルと呼んでいるものは、実際にはコントローラのみです。
3. あなたが本当にモデルを持ちたいなら、それは彼らの「データ」がどこかにあるでしょう。

アプリでQtモデル/ビューコンポーネントを使用する通常の方法について話しています。理由は次のとおりです。

1. これは通常、オブジェクトに固有のコントローラーロジックを追加せずに、そのまま使用されるQtコンポーネントです）
2. これはモデルではありません。モデルとは何の関係もない、rowCount、columnCount、dataなどのいくつかのQtメソッドを実装する必要があるからです。実際、コントローラーには典型的なモデルメソッドがあります。もちろん、ここでコントローラーとモデルの両方のロジックを実装できますが、最初はコード設計が非常に悪くなり、次に、コントローラーとビューではなく、コントローラーとモデルをマージします。
3. 理由2で述べたように、モデルロジックを分離したい場合、それは確かに画像の青いボックスではなく、破線の「データ」ボックスです（もちろん、実際のデータと通信しています）。

Qtの用語が間違っていますか、それとも理解できないのは私だけですか？（ところで、それが学術的な問題ではない理由は、プロジェクトの命名に続いてコードを書き始めたのですが、すぐにコードが正しくないことに気づきました。それが後になって初めて、彼らがモデルと呼ぶものにモデルロジックを入れないでください）

Qtの命名が誤解を招くものであることに同意します。ただし、私の意見では、問題はQtだけではなく、UIを実装するときに懸念の分離の原則に準拠できるようにするすべてのフレームワークによって共有されます。誰かがそのようなフレームワークを思いついて、「もの」を分離しておく良い方法を見つけたとき、彼らは常に「モデル」と呼ぶモジュールと「ビュー」と呼ぶモジュールを持っている義務があると感じています。長年にわたり、私はこれらのフレームワークを使用してきました：

• MFC
• Qt
• スイング
• SWT
• MVVMを使用したWPF

これらのフレームワークで「モデル」と「ビュー」という用語がどのように使用されているかを比較し、「ビュー」、「モデル」、および「コントローラー」（存在する場合）のク​​ラスにどのような責任があるかを比較すると、非常に大きな違いがあることがわかります。異なる概念や用語を比較すると、あるフレームワークから別のフレームワークに切り替える人が正気を保つことができるようになりますが、多くの作業と調査が必要になります。読みやすいのは、Martin Fowlerの概要です。

非常に多くの異なる考えがあるので、どのようなMVCパターンは1つが正しいとする、のように見えることができますか？私の意見では、MVCを発明した人々は、それがどのように「正しく」実装されることになっているのかを知りたいときに頼るべきです。で、元のSmalltalkの紙それは言います：

ビューは、そのアプリケーションに割り当てられているビットマップ表示の部分へのグラフィックおよび/またはテキスト出力を管理します。コントローラーは、ユーザーからのマウスとキーボードの入力を解釈し、必要に応じてモデルやビューに変更を指示します。最後に、モデルはアプリケーションドメインの動作とデータを管理し、その状態に関する情報の要求（通常はビューから）に応答し、状態を変更する指示（通常はコントローラーから）に応答します。

それを踏まえて、私はあなたの3つの主な懸念にこう答えます。

1. 実際、Qtコンポーネントは「グラフィカルな[...]出力を管理」し、「マウスとキーボードの入力を解釈する」ので、上記の定義に関して、実際にはマージされたビューとコントローラーと呼ぶことができます。
2. 私はあなたがコントローラーとモデルをマージすることを強制される/することに同意します（ここでも上記の定義に関して）。
3. 私も同意します。モデルは、アプリケーションドメインのデータのみを管理する必要があります。これが「データ」と呼ばれるものです。明らかに、たとえば行や列を扱うことは、通常、アプリケーションドメインとは何の関係もありません。

どこに行きますか？私の意見では、「モデル」と「ビュー」という用語が使用されているときにQtが実際に何を意味するのかを理解し、Qtでプログラミングしている間、それらの方法で用語を使用するのが最善です。煩わしさを感じ続けると、速度が低下するだけで、Qtでの設定方法によってエレガントなデザインが可能になります。これは、「間違った」命名規則よりも重要です。

短い答え

QtのMVCは1つのデータ構造にのみ適用されます。MVC アプリケーションについて話すときは、QAbstractItemModelまたはについて考えるべきではありませんQListView。

プログラム全体にMVCアーキテクチャが必要な場合、Qtにはそのような「巨大な」モデル/ビューフレームワークはありません。しかし、プログラムのデータのリスト/ツリーごとに、実際にはビュー内にコントローラーがあるQt MVCアプローチを使用できます。データは、内部または外部のモデルです。これは、使用しているモデルのタイプに依存します（独自のモデルサブクラス：おそらくモデル内。例：QSqlTableModel：外部（ただし、モデル内にキャッシュされる可能性があります））。モデルとビューを組み合わせるには、ビジネスロジックを実装する独自のクラスを使用します。

長い答え

Qtのモデル/ビューのアプローチと用語：

Qtはモデルにシンプルなビューを提供します。彼らは持っているコントローラの項目を編集し、移動、選択、ほとんどの場合、何か何コントローラ「コントロール」です：に建てられています。つまり、ユーザー入力（マウスのクリックと移動）を解釈し、適切なコマンドをモデルに与えます。

Qtのモデルは確かに基礎となるデータを持つモデルです。もちろん、Qtはそれらをどのように格納したいのかわからないため、抽象モデルはデータを保持しません。しかし、あなたはサブクラスにあなたのデータコンテナを追加し、あなたのデータにアクセスするモデル・インタフェースを作ることによって、あなたのニーズにQAbstractItemModelを拡張します。したがって、実際には、これが気に入らないと思いますが、問題は、モデルをプログラムする必要があることです。つまり、データにアクセスし、データ構造で変更する方法です。

MVC用語では、モデルにはデータとロジックの両方が含まれます。Qtでは、ビジネスロジックの一部をモデルの中に含めるか、それを外部に置くか、それ自体が「ビュー」であるかは、あなた次第です。ロジックの意味すら明確ではありません。アイテムの選択、名前の変更、移動はどうでしょうか。=>すでに実装されています。それらを使って計算していますか？=>モデルサブクラスの外側または内側に配置します。ファイルとの間でデータを保存またはロードしますか？=>モデルサブクラス内に配置します。

私の個人的な意見：

良い提供することは非常に困難であるとプログラマに一般的なMV（C）システムを。ほとんどの場合、モデルは単純なため（たとえば、文字列リストのみ）、Qtはすぐに使用できるQStringListModelも提供します。しかし、データが文字列よりも複雑な場合は、Qtモデル/ビューインターフェースを介してデータをどのように表現するかはあなた次第です。たとえば、3つのフィールドを持つ構造体（名前、年齢、性別を持つ人物など）がある場合、3つのフィールドを3つの異なる列または3つの異なるロールに割り当てることができます。どちらのアプローチも嫌いです。

Qtのモデル/ビューフレームワークは、単純なデータ構造を表示する場合にのみ役立つと思います。データがカスタムタイプであるか、ツリーやリスト（グラフなど）で構造化されていない場合、処理が難しくなります。ほとんどの場合、リストで十分であり、場合によっては、モデルは単一のエントリのみを保持する必要があります。特に、異なる属性を持つ1つのエントリ（1つのクラスの1つのインスタンス）をモデル化する場合、Qtのモデル/ビューフレームワークは、ロジックをユーザーインターフェイスから分離する適切な方法ではありません。

まとめると、Qtのモデル/ビューフレームワークは、データがQtのビューアウィジェットの 1つで表示されている場合にのみ役立つと思います。アプリケーションの設定など、1つのエントリのみを保持するモデルの独自のビューアを作成する場合や、データが印刷可能なタイプでない場合は、まったく役に立ちません。

（より大きい）アプリケーション内でQtモデル/ビューをどのように使用しましたか？

私はかつて、複数のQtモデルを使用してデータを管理するアプリケーションを（チームで）作成しました。DataRole異なるモデルサブクラスごとに異なるカスタムタイプの実際のデータを保持するを作成することにしました。Modelすべての異なるQtモデルを保持するという外部モデルクラスを作成しました。またView、内のモデルに接続されているウィンドウ（ウィジェット）を保持するという外部ビュークラスも作成しましたModel。したがって、このアプローチは、Qt MVCの拡張であり、私たち自身のニーズに適合しています。ModelとViewクラス自体は、Qt MVCとは何の関係もありません。

ロジックをどこに配置しましたか？ソースモデルからデータを読み取り（変更された場合）、結果をターゲットモデルに書き込むことにより、データの実際の計算を行うクラスを作成しました。Qtの観点から見ると、このロジッククラスはモデルに「接続」するため、ビューになります（ユーザーの「ビュー」ではなく、アプリケーションのビジネスロジック部分の「ビュー」）。

コントローラはどこにありますか？元のMVC用語では、コントローラーはユーザー入力（マウスとキーボード）を解釈し、要求されたアクションを実行するコマンドをモデルに提供します。Qtビューはアイテムの名前変更や移動などのユーザー入力をすでに解釈しているため、これは必要ありませんでした。しかし、必要なのは、Qtビューを超えるユーザーインタラクションの解釈です。

用語は正しいか間違っているかではありません、それは役に立つか役に立たないです。

質問を少し変えて、QtがMVCに適さない理由を尋ねるかもしれません。答えは、初期のQt開発者は、GUIアプリケーションでVをCから分離することは、VとCの両方に悪い影響を与えると信じているということです。QWidgetの設計は、マウス入力の操作をピクセル出力の決定と密接に結び付けることを簡単にすることを試みており、それがMVCへの道ではないことがわかります。

モデルの機能は、情報の要求に応答するように、私はこのような方法を定義する上で何も間違っがあると思いrowCount、columnCountなど、私は（関係なく、それはSQLテーブルまたは単にアレイものです）モデルは、データ・ソースのラッパーのいくつかの種類だと思います、データを標準形式で提供します。メソッドを定義する必要があるのは、データソースの構造によって異なります。

彼らの用語は正しいと思います...実際のアプリケーションでは、抽象化のレベルによっては、モデル、ビュー、コントローラーの間の線をぼかすのが非常に簡単になる場合があります。

QAbstractModelItemクラスから混乱が生じているように感じます。このクラスはモデルアイテムではなく、モデルへのインターフェイスです。ビュークラスをモデルとインターフェイスさせるには、モデルへの一般的な抽象インターフェイスを作成する必要がありました。ただし、モデルは、単一のアイテム、アイテムのリスト、アイテムの2つ以上の次元のテーブルなどにすることができます。したがって、それらのインターフェースは、これらすべてのモデルのバリエーションをサポートする必要があります。確かに、これはモデル項目をかなり複雑にし、実際のモデルで機能させるためのグルーコードはメタファーを少し伸ばしているようです。

私はそう思います...彼らがモデルと呼ぶものは、実際にはコントローラーのみです。

いいえ、彼らの「モデル」はコントローラではありません。

コントローラは、モデルを変更する（したがって、ビューを間接的に変更する）ユーザーに表示されるコントロールの一部です。たとえば、「削除」ボタンはコントローラの一部です。

多くの場合、「コントローラがモデルを変更する」のようなものを見るので混乱があると思います。これは、「deleteRow（）」メソッドのような、モデルの変更機能を意味すると思います。ただし、クラシックMVCでは、コントローラーは特にユーザーインターフェイス部分です。モデルを変更するメソッドは、単にモデルの一部です。

MVCが発明されて以来、コントローラーとビューの違いはますます緊張してきています。テキストボックスについて考えてみましょう。テキストボックスが表示され、編集できるので、ビューとコントローラーのどちらですか。答えは、それが両方の一部であるということでなければなりません。1960年代にテレタイプに取り組んでいた頃は、その違いはより明確でしたed– 考えてみてください–しかし、それは、当時のユーザーにとってより優れていたということではありません。

QAbstractItemModelがモデルが通常よりもかなり高いレベルであることは事実です。たとえば、その中のアイテムは背景色（技術的にはブラシ）を持つことができます。これは明らかに見栄えの良い属性です！したがって、QAbstractItemModelはよりビューに近く、データはモデルであるという議論があります。真実は、ビューとモデルの古典的な意味の中間にあるということです。しかし、それがコントローラーなのかわかりません。どちらかと言えば、それを使用するQTウィジェットです。