13

新しいサイトを開発するために MVC を選択したことで、自分の周りで「ベスト プラクティス」が明らかにリアルタイムで開発されている最中にいることに気づきました。2 週間前、NerdDinner は私のガイドでしたが、MVC 2 の開発により、時代遅れに見えます。それはスリリングな経験であり、インテリジェントなプログラマーと毎日密接に接触できることを光栄に思います。

現在、すべてのブログから直接回答を得られないように思われる問題に出くわしました。コミュニティから洞察を得たいと思います。編集についてです (読み: 編集アクション)。そこにあるチュートリアルやブログなどの資料の大部分は、モデルの作成と表示を扱っています。ですから、この質問は質問を綴っていないかもしれませんが、私が進むべき開発の道についての私の決定に貢献するために、いくつかの議論を進めたいと思っています.

私のモデルは、名前、住所、電子メールなどのいくつかのフィールドを持つユーザーを表します。実際、フィールド上のすべての名前は、ファーストネーム、ラストネーム、ミドルネームのそれぞれです。[詳細] ビューにはこれらのフィールドがすべて表示されますが、一度に変更できるのは、名前などの 1 つのフィールド セットのみです。他のフィールドが上下に表示されている間に、ユーザーがフォームを展開します。したがって、ポストバックされるフォームには、モデルを表すフィールドのサブセットが含まれます。

これは私たちと私たちのレイアウトの懸念事項にとって魅力的ですが、さまざまな理由から、真面目な MVC 開発者は避けなければなりません。私はいくつかのパターンとベスト プラクティスについて読んできましたが、これは viewmodel == view のパラダイムとは関係がないようです。それとも私はそれを間違っていますか？

とにかく、NerdDinner は FormCollection または UpdateModel の使用を指示します。null フィールドはすべて無視されます。それ以来、MVC コミュニティはこのアプローチを放棄しており、MVC 2 のバグは発見されていません。UpdateModel は、フォーム コレクションに完全なモデルがないと機能しません。

最も賞賛されているビュー モデル パターンは、カスタム ビュー モデル エンティティを含む専用ビュー モデルのようであり、私の設計上の問題と互換性を持たせることができる唯一のビュー モデルです。AutoMapperの使用と Jimmy Bogardのアイデアによって軽減されたとはいえ、退屈な量のマッピングが必要になりますが、それは価値がある場合とない場合があります。また、ビューとビュー モデルの 1 対 1 の関係も提案しています。

これらの設計パラダイムに沿って、拡大する一連のフィールドごとにビューと関連するビューを作成します。ビュー モデルはそれぞれほぼ同じで、読み取り専用のフィールドのみが異なり、ビューにも多くの繰り返しマークアップが含まれます。これはばかげているように思えます。将来的には、2 つ以上、またはすべてのフィールド セットを同時に開いて表示できるようにしたいと思うかもしれません。

私は、私が火をつけたいと思っている議論を最も注意深く読みます。よろしくお願いします。

4

4 に答える 4

3

私はこのようにしています（マッピングは、 valueInjecter を使用してmodelBuilder内で自動的に行われます）：

サンプルの asp.net-mvc アプリケーションがあり、mvc でこれを行うベスト プラクティスを示しています。valueinjecter のダウンロードで確認できます。

 public ActionResult Edit(long id)
 {
      return View(modelBuilder.BuildModel(personService.Get(id)));
 }

 [HttpPost]
 public ActionResult Edit(PersonViewModel model)
 {
    if (!ModelState.IsValid)
       return View(modelBuilder.RebuildModel(model));    
       personService.Save(modelBuilder.BuildEntity(model));
       return RedirectToAction("Index");
 }

ValueInjecterの簡単なデモ:

//build viewmodel
    personViewModel.InjectFrom(person)
                   .InjectFrom<CountryToLookup>(person);

//build entity
    person.InjectFrom(personViewModel)
          .InjectFrom<LookupToCountry>(personViewModel);
于 2010-06-11T06:52:16.743 に答える
2

最近、モデルの検証の問題に関する投稿がいくつかありました。その結果、Brad Wilson によるこの投稿「ASP.NET MVC での入力の検証とモデルの検証」が生まれました。

最初の問題は、ASP.NET MVC が投稿されたモデルの検証を処理する方法と、編集したくないモデルの要素があり、ビューでフィールドを提供しなかったが、コントローラーが動作していた場合でした。モデル全体、誰かが追加のフィールドを使用してコントローラーへの POST を作成できる可能性があります。

したがって、ビュー固有のモデルを使用すると、編集するフィールドのみを編集できるようにすることができます。

于 2010-01-26T23:12:44.420 に答える
0

これをチェックしてください。これは、ASP.NETMVC2を使用する方法です。

        public void Update(MyModel model)
        {
            var myModelObject = MyRepository.GetInstance(model.Id);
            if(myModelObject != null)
            {
                ModelCopier.CopyModel(model, myModelObject);
            }
            MyRepository.Save(myModelObject);
        }

ModelCopier.CopyModel（obj from、obj to）は、最新のMvcFuturesの新しい関数です。また、MVCFutures2のExtensibleModelBinderも必ずチェックしてください。

于 2010-04-08T20:36:23.587 に答える
0

私はまったく同じ問題を抱えていますが、それをうまく定式化することはできません。

私の場合、さまざまなユーザーが一連の役割に基づいてさまざまなフォームを表示するため、大量のViewModelが存在します。ViewModelとViewの1：1の関係は非常にあいまいだと思います。非常に単純に使用し、それ以上ではないuber-Viewを作成するとどうEditorForModelなりますか？これで、非常に縮退しているものの、すべてのビューが1つあるので、ViewModelも1つしかありません。

私のアイデアはEditorForModel、リフレクション（つまり、コンパイル時に知られている情報）だけでなく、たとえば現在のユーザーの役割や現在の時刻などによって管理される（ドメイン固有の）ランタイムルールにも基づいて機能するを作成することでした。 、ModelBinderモデルからViewModelへのカスタムマッピングだけでなく、検証付きのカスタムも作成する必要があります。それでも、これは私が愚かな、したがってエラーが発生しやすいコードを書くことを防ぎます。

私のモデル（またはDomainModel）には多くのロジックが含まれているため、ModelBindingを介して変更する必要はありません。さらに、コンパイル時にどのフィールドが存在するかを知ることは不可能であるため、適切なViewModelを提供することは不可能です。ただし、「フル」、つまり最大のViewModelは既知です。ViewModelからModelへのマッピングにもカスタムコードが含まれますが、ルールを形式化できる限り、それはうまくいくはずです。

申し訳ありませんが、私のテキストは非常に混乱していますが、私は今自分自身で非常に混乱しています、そして私は走らなければなりません。CTのように、コメントすることもできませんでした。

于 2010-01-25T17:29:59.290 に答える