5

Automapperを使用するか手動マッピングを使用するかにかかわらず、それは何の役割も果たしません。

ReleaseViewModelのすべてのデータは、データアクセス層に入力されるため、リリースの最初にある必要があります。私のモデルの90％はこのようなものです。なぜすべてを複製するオーバーヘッドがあるのですか？

KISSの原則と過剰設計についてはどうですか？

もちろん、適切なタスクのためのすべてのツールですが、asp.netmvcでViewModelsを使用しないことはNO-GOであるとSOでよく読んでいます。

どこに線を引くか？モデルと50％、75％、または99％区別する場合、ViewModelsを使用する必要がありますか？

私はモデルリリースを持っています：

 public class Release
    {      
        public int Id { get; set; }       
        public string Name { get; set; }
        public string Author { get; set; }
        public DateTime CreatedAt { get; set; }
        public int FailedTestsCount { get; set; }
        public int SucceededTestsCount { get; set; }
        public int SumTestsCount
        {
            get
            {
                return SucceededTestsCount + FailedTestsCount;
            }
        }
        public int SumTestingTime { get; set; }
    }

ビューモデルReleaseViewModel：

public class ReleaseViewModel
{
    [HiddenInput(DisplayValue = false)]
    public int Id { get; set; }

    [Required(ErrorMessage = "Name must not be empty.")]
    [StringLength(30, ErrorMessage = "Enter max. 30 chars for a name.")]
    [Remote("ReleaseExists", "Release", ErrorMessage = "This name already exists.")]
    public string Name { get; set; }    
    public string Author { get; set; }    
    public DateTime CreatedAt { get; set; }    
    public int FailedTestsCount { get; set; }    
    public int SucceededTestsCount { get; set; }    
    public int SumTestsCount 
    {
        get
        {
            return SucceededTestsCount + FailedTestsCount;
        }
    }

    public int SumTestingTime { get; set; }
}
4

5 に答える 5

5

ViewModelVIEW用のものです。ほとんどの場合、エンティティモデルに似ています。しかしいつもではない。

あなたの例を見てください。にViewModelは、Remote属性といくつかの検証属性があります。したがって、このリモート名チェックは、ユーザーエクスペリエンスを向上させるために追加するものです。これはビューに固有です。

ビューモデルが必要なもう1つのシナリオは、複数のモデルが関係している画面の場合です。例：UserエンティティとProjectエンティティがあり、プロジェクトをユーザーに追加できる画面を提供したいとします。したがって、この場合、それを処理するためのビューモデルを作成できます

public class ProjectToUserVM
{
  public int UserId { set;get;}
  public string UserName { set;get;}  // i want to display only name of user!
  public int ProjectID { set;get;}
  public IEnumerable<SelectListItem> Projects { set;get}
}

すべてのモデルエンティティにViewModelsを使用しないでください。VIEWが本当に必要なときに作成します。モデルエンティティオブジェクトは、まったく同じであるため、ビューモデルを作成せずに一部のビューで直接使用します。例：国/州/市（テーブルデータを検索します。追加/編集なし）

于 2012-06-26T19:34:54.627 に答える
2

なぜすべてを複製するオーバーヘッドがあるのですか？

まず第一に、あなたは私がコードを複製していると思うかもしれませんが、実際にはあなたはそうではありません、あなたがそれをしている場合、あなたは深刻な設計上の問題を抱えています

私は、あなたがそれに従わないとき、それが本当にすべての悪の根源であるという1つの原則があることを発見しました：SRP（単一責任原則）

おそらく、問題がまだ見つかっていないためか、問題があり、コードにパッチを適用したばかりである可能性があります。ドメインオブジェクトの責任は、ユーザーにデータを提示する責任とはまったく異なります。

MVCのモデルは、ビューがレンダリングする必要のあるすべてのデータを表すクラスである必要があり、それ以上のものはありません。このモデルにドメインのデータを入力する必要があります。（またはCQRSアーキテクチャでは、クエリサービスから）

CQRSアーキテクチャに従う場合（少なくとも基本的には、コマンドをクエリから分離するためにイベントソーシングを実装したり、サービスバスを使用したりする必要はありません）、これはより明確になります。クエリオブジェクトの責任は次のとおりです。コマンドオブジェクト（ドメインからのアクション）とは完全に異なります

KISSの原則を誤解していると思いますが、コードやYAGNIの過剰設計について説明していますが、アプリケーションですべてを再利用する必要があるわけではありません。

私を信じてください、私はこれが悪い方法であることを学びました=（、再利用されるべき唯一のコードはインフラストラクチャコードです、ドメインコードについて話すとき、常にSRPに従う方が良いです

于 2012-06-26T19:39:50.743 に答える
1

私のViewModelsは単にモデルをラップし、90％の確率でモデルに委任します。特定のビューのユースケースでモデルの動作について何かを変更する必要がある場合にのみ、独自の動作があります。そこにVMがあると、表示目的でのみ必要な動作を追加するのがはるかに簡単になります。特に、その動作が永続化モデルに干渉する場合（たとえば、永続化したくないプロパティを追加する場合）。

また、CastleやSpringFramework.netなどのIoCツールを使用して、デフォルトの転送動作をオンザフライで生成し、手動で記述する必要のあるコードの量を減らすことができることも注目に値します。これにより、「複製コスト」が大幅に削減されるため、最初のように悪くはありません。

于 2012-06-26T19:08:41.077 に答える
0

私はShyjuが言うすべて、特に「あなたがそれを必要とするとき」についての部分を2番目にしています。

EntityModelクラスがViewModelクラスと同じライブラリにある非常に単純なプロジェクトの場合、個別のViewModel dtoは必要なく、それらを放棄することができます。「ビューモデル、デュマにエンティティクラスを使用しているため、これを間違えた」と賢明な人が言うことはないと思います。アプリケーションのコンテキストが何であるかはわかりません。あなたの場合、それは完全に適切かもしれません。

私たちの中には、大規模なプロジェクトのために、非Webアセンブリ（DLLにコンパイルされる単なるクラスライブラリ）でEntityModelsを定義する人もいます。この場合、質問例のRemoteAttributeやHiddenInputAttributeなど、特別な属性をビューにのみ適用する必要があることがよくあります。ただし、個別のviewmodel dtoレイヤーを使用せずにこれを行うには、System.Web.Mvc.dllへの参照をEntityModelライブラリに追加する必要がありますが、実際には、ライブラリはWebとは関係がありません。

WebプロジェクトでEntityModelクラスを再利用する場合（つまり、ストレージモデルとプレゼンテーションモデルの両方として使用する場合）、プロジェクトのWebの側面とプロジェクトのビジネスの側面の間に緊密な結合が作成されることに注意してください。コスト/予算、時間、ターゲットオーディエンス、範囲、またはその他の制約のためにこれを正当化できる場合は、それを実行し、批評家はあなたほど全体像を見ていないので無視します。

于 2012-06-26T19:52:00.733 に答える
0

ReleaseクラスがINotifyPropertyChangedと、ビューに必要な他のすべてのもの（検証、コマンドなど）を実装している場合は、ビューモデルを使用する必要はありません。しかしそうでない場合は...

于 2012-06-27T11:37:09.833 に答える