0

ビューモデルを構成するものはまだ完全にはわかりません。モデルをラップしてデータを少し変更するために使用するクラスがありますが、それがビュー モデルを構成するかどうかはわかりません。ビューモデルと見なされるには何が必要ですか? ビューがそのプロパティをどのように使用しているかをビューモデルが認識せず、ビューがビューモデルの内容を認識しないように、ビューに直接依存することは想定されていませんか? ビューが何かを更新したいときは、ビューモデルがモデルを更新するために取得して使用する抽象的なコマンドを与えるだけですか?

MVVMで理解しているように、モデルのプロパティにバインドするビューモデルのプロパティにバインドするビューのプロパティを使用することになっています。

逆方向では、ビューからビューモデルへのコマンドを使用することになっています。これにより、Icommand を使用してモデルにコマンドを実行するか、モデル内のパブリック関数を呼び出して変更を加えることができます。

紛らわしいことの 1 つは、私が見た MVVM の例では、MVVM のように見えて、おそらくコマンドを作成する以外にビューにコードが含まれていないことですが、現在のプロジェクトでそれを行う方法がわかりません。イベントで相互作用する多くのコントロールを使用して、カスタム コントロールを作成しています。

イベントを使用せずに、あるツリービューを別のツリービューの展開で展開するにはどうすればよいですか?

4

2 に答える 2

2

多くの場合、ビュー モデルはドメイン モデルに非常に似ています。ビュー モデルを持つ主な目標の 1 つは、GUI 開発をビジネス ロジックから分離することです。たとえば、ビューに公開したくない IsAdmin プロパティを持つ "User" ドメイン モデルがあるとします。「UserViewModel」というビュー モデルを作成します。このビュー モデルには ID、ユーザー名、およびパスワードが含まれていますが (以下のサンプル コードを参照)、IsAdmin プロパティはありません。もう 1 つの方法は、ビュー モデル内でドメイン モデルを使用することです。以下の「AlternateUserViewModel」クラスを参照してください。どのビュー モデル ソリューションにも長所と短所があります。プロパティを持つ UserViewModel クラスを作成するということは、ドメイン モデル用に作成したオブジェクトを本質的に複製していることを意味します。多くの場合、ドメイン モデルはビュー モデルと非常によく似ています。AlternateUserViewModel アプローチでは、ビュー モデルがドメイン モデルについて「認識する」必要があるため、ビジネス ロジック層と GUI 層の間に明確な分離はありません。どのアプローチを決定するかは、実際に作業している環境によって異なります。個人的なプロジェクトでは、2 番目のアプローチを使用するのが好きです。なぜなら、ビジネス ロジックをデザイン レイヤーから分離することは、私がさせたくないほど大きな懸念事項ではないからです。ビュー モデル レイヤーはドメイン モデル レイヤーを「参照」しますが、デザイン レイヤーとバックエンドで別々のチームが作業している大企業では、最初のアプローチが好まれる場合があります。ビューモデルはドメインモデルについて「知る」必要があるため、ビジネスロジックレイヤーとGUIレイヤーの明確な分離はありません。どのアプローチを決定するかは、実際に作業している環境によって異なります。個人的なプロジェクトでは、2 番目のアプローチを使用するのが好きです。なぜなら、ビジネス ロジックをデザイン レイヤーから分離することは、私がさせたくないほど大きな懸念事項ではないからです。ビュー モデル レイヤーはドメイン モデル レイヤーを「参照」しますが、デザイン レイヤーとバックエンドで別々のチームが作業している大企業では、最初のアプローチが好まれる場合があります。ビューモデルはドメインモデルについて「知る」必要があるため、ビジネスロジックレイヤーとGUIレイヤーの明確な分離はありません。どのアプローチを決定するかは、実際に作業している環境によって異なります。個人的なプロジェクトでは、2 番目のアプローチを使用するのが好きです。なぜなら、ビジネス ロジックをデザイン レイヤーから分離することは、私がさせたくないほど大きな懸念事項ではないからです。ビュー モデル レイヤーはドメイン モデル レイヤーを「参照」しますが、デザイン レイヤーとバックエンドで別々のチームが作業している大企業では、最初のアプローチが好まれる場合があります。

public class User
{
    public int ID { get; set; }
    public string Username { get; set; }
    public string Password { get; set; }
    public bool IsAdmin { get; set; }
}

public class UserViewModel
{
    public int ID { get; set; }
    public string Username { get; set; }
    public string Password { get; set; }
}

public class AlternateUserViewModel
{
    public User User { get; set; }

    public User ToDomainModel()
    {
        if (User == null)
            return null;

        // if this is an existing user, retrieve it from the database so you're not overwriting the IsAdmin property
        if (User.ID != default(int))
        {
            User existingUser = UserService.GetUserByID(User.ID);
            existingUser.Username = User.Username;
            existingUser.Password = User.Password;
            // IsAdmin is not set because you don't want that property exposed in the View Model
            return existingUser;
        }
        else
        {
            return new User
                       {
                           Username = User.Username,
                           Password = User.Password,
                           IsAdmin = false
                       };
        }
    }
}
于 2013-09-07T01:31:33.657 に答える
1

ここにはいくつかの質問があります (複数の投稿に分割することを検討してください)。いくつか答えてみます。

私は ViewModel をTHEアプリと考えています。つまり、アプリのロジックのほとんどがここで行われます。

つまり、ViewModel は次の入力を受け取ります。

  • ビューからのコマンド
  • ビューからのバインドされたプロパティの変更
  • バックグラウンド サービスからのイベント (例: Web からデータを受信したとき)
  • システムまたはドメイン モデルからのその他のイベント

次の出力を生成します。

  • ビューがバインドするプロパティの変更 (たとえばIsBusy、ビューが待機インジケーターを表示する可能性があります)
  • ビュー内のものを表示/非表示にする (もちろん、さまざまな bool プロパティを使用するなど、間接的に)
  • 他のビューへのナビゲーションを引き起こします (ビューに直接アクセスできないため、間接的にもNavigatonService)。

ViewModel について考える別の方法は次のとおりです。ViewModel は、システムの完全なユーザー向け状態です。言い換えれば、この状態だけがビューによって使用され、ユーザーが理解できる方法でこの状態を表示/提示します。

コマンドとイベントについて:

残念ながら、WPF のすべてが として公開されているわけではありませんCommand。ボタンは を生成Commandしますが、すべてのコントロールが生成するわけではありません。幸いなことに、ビヘイビアを使用してイベントをコマンドに変換でき、一部のフレームワークが実装を提供します。MVVM Light がこれを行う方法の例を次に示します。Blend もこの機能を提供します。

Commandまた、コード ビハインドで sを生成する必要があるのはなぜですか? MVVMLight のようなフレームワークは、RelayCommand(またはDelegateCommand) の実装を提供するため、さまざまな実装を作成する必要がなくなりますICommand。自分で簡単に実装できます。

于 2013-09-07T02:27:04.950 に答える