質問: View Modelもあります。 * .. 私は、「それに依存する」答えがここにあることを知っています。 しかし、それは何に依存するのですか? あなたはどちらのアプローチを使っていますか、それをどのように見直しますか? 共有してくれてありがとう、 よろしく、 コーエン
回答: MVVMをデザインパターンとして使用して以来、私はその使用を大いに支持しています。私は最近、MVVMを使用して大規模な製品のUIコンポーネントを作成したチームの一員で、すべてのデータベース呼び出しなどを処理するサーバーアプリケーションとやり取りしました。正直言って、これは私が取り組んできたプロジェクトの中で最高のものでした。 このプロジェクトは、 * データモデル(InotifyPropertyChangedをサポートしない基本クラス)、 * モデルの表示(INPC、関連ビューのすべてのビジネスロジックをサポート)、 * 表示(XAMLのみ)、 * モデルを転送する(データベースを呼び出すメソッドのみ) Transferモデルを1つのクラスに分類しましたが、実際には複数のレイヤーとして構築されていました。 私はまた、追加の機能を追加したり、データの表示方法を変更したりするために、Modelクラスのラッパーである一連のViewModelクラスを用意しました。これらはすべてINPCをサポートしており、私のUIがバインドされたものです。 私は、MVVMのアプローチが非常に有用であることを発見しました。そして、すべての正直なところでは、コードはシンプルに保たれました。それぞれのビューは、そのビューのビジネスロジックを処理する対応するビューモデルを持っていました。 私は、このようなコードを分けておくと、物事を分かりやすくしていると思います。それぞれのView Modelは、ビューに関連するものしか含まれていないために混乱する危険はありません。繰り返しコードを減らしてください。 もちろん、このコードの利点は、データベースへの呼び出しが、アプリケーションへの呼び出しによってデータベースへの呼び出しが処理されたために、コードが即座にメンテナンス可能になるということです。これは、サービスメソッドの動作が変更される可能性がある返され、必要なパラメータは、UIがこれについて知る必要はありません。同じことがUIのためにあり、コードビハインドのないUIを持つことは、UIを非常に簡単に調整できることを意味します。 欠点は、実際にMVVMに固執し、いくつかの複雑な解決策を理解したくない場合を除き、何らかの理由でコードの背後にあるコードで悲しいことですが、実際のMVVMの実装に固執するのは難しい場合もあります私たちはこれをコードの背後にあるとは考えていませんでした)。 結論として、継承を適切に使用し、設計パターンに固執し、コーディング標準を適用すると、このアプローチは非常にうまくいくと思いますが、逸脱し始めると物事が乱雑になり始めます。