ロングネームを避けるためのビューモデルに関する命名規則

Question

私はASP.NET MVCアプリケーションの各画面に対してのビューモデルを作成しています。 ビルダークラスにビューモデルを作成するためのすべてのロジックを入れました。通常、集計、フィルタリング、ソートなど、データオブジェクトをビューモデルに変換する特別なロジックがあります。各ビルダーには、の依存関係セットが渡されます。これは、各依存関係（リポジトリ、他のビルダーなど）のプロパティを含むオブジェクトです。

問題は、私の名前は本当に長くなっていることです。依存関係セットは、通常は名前がこのように構成されます：

ビューモデル名+ Builderの+ DependencySet

ビューモデルは通常あなたが現在いると子供どこで構成される名前を持っています。たとえば、私のシステムはプロバイダ定義を分類しています。だから、カテゴリの下にプロバイダの定義を示すために、私は、ビューモデルを求めている：

CategoryProviderDefinitionListViewModel

それは次のようになります。

だから、

public sealed class CategoryProviderDefinitionListViewModel 
{ 
    public long CategoryId { get; set; } 
    public string CategoryName { get; set; } 
    public ProviderDefinitionViewModel[] ProviderDefinitions { get; set; } 
} 

、私のビルダーが呼び出される

CategoryProviderDefinitionListViewModelBuilder

だから、私の依存関係セットは

CategoryProviderDefinitionListViewModelBuilderDependencySetかろうじて画面全体に収まる

と呼ばれています。私の貧弱な指は疲れている。さらに、一部の画面ではほとんど同じデータが表示されるため、ビューのモデル名はほとんど同じです。私のフォルダを見ていると、私が探している特定のビューモデルのクラスを見つけることが本当に難しくなります。

理想的には、ビューモデルクラスをグループ化して、ビューを使用するビューに関連付けることができます。衝突を避け、名前をできるだけ短くして意味のあるものにするのは良いことです。このシナリオでうまく動作する命名規則/フォルダ構成を見つけた人はいますか？

Answer 1

私はずっと "ViewModel"という接尾辞を一貫して使用してきました。正直言って、時には冗長であることがあります。私は、これらのクラスをすべて別の名前空間にまとめるだけで十分だと思います。

私の理解では、（例えば製品対ProductViewModel）この規則は、ドメインモデルとビューモデルクラス間の衝突を回避するために採用されているということです。ただし、ビューモデルの名前は画面の名前に基づいているため、ドメインモデルに同じ名前のクラスがあることはほとんどありません。実際には、ドメインモデルにこのようなクラスがある理由は本当に疑問です。:)あなたがViewProductのようなあなたのビューモデルの何かに名前を付ける場合

だから、（ユーザーが/閲覧製品を編集できるように）、あなたはそれViewProductViewModel呼び出す必要はありません。私がどこに行くのか見て？

その結果、あなたのビルダークラスは単にViewProductBuilder代わりのViewProductViewModelBuilderと呼ばれることがあります。

あなたの依存関係セットに関して、私はこの背後にあなたの根拠が何か分かりません。しかし私にはそれは不必要に見えます。ビルダーが他のオブジェクトに依存している場合は、別のクラス（DependencySet）にカプセル化して渡す代わりに、ビルダーのコンストラクターに依存関係を注入する必要があります。

BuilderがDependencySetの背後に隠そうとしていることがあまりにも多すぎることに気づいた場合、それは他の場所のデザインの匂いの兆しである可能性があります。クラスとその依存関係が適切なオブジェクト指向の方法で設計されている場合、動作はさまざまなクラス間で非常にうまく分散されなければならず、クラスはあまりにも多くの他のものに依存するべきではありません。だから、1つのクラス（DependencySet）でN個の依存関係を隠すだけでは、問題自体ではなく症状を扱うことになります。

・ホープ、この助け:)

Answer 2

私は "DTO" と私のViewModelに名を定着後好みます。 （DTOはデータ転送オブジェクトの略で、情報を含むだけのオブジェクトです）

これは長い名前を避けるためだけではありません。しかし、それはユーザーのような同じ名前を使用することもできますが、それはUserDTOと呼ばれ、私のViewModelの一部であるオブジェクトを扱っているので、名前の衝突を避けています。

Answer 3

私はMoshに同意する傾向があります。

ほとんどの場合、ViewModelのサフィックスは冗長になります。また、クラス名が一致することもありますが、ViewModel名前空間に限定されているため、管理が簡単です。私はまた、奇妙な名前空間エイリアスを使用すると、私の脳を傷つけ、ボード全体にわたって自分のクラス名に接尾辞を付けるよりも少なくなることがわかります。

もちろん、プレゼンター/コントローラーで名前の衝突が発生する可能性がありますが、これは、あなたのビューの名前をもっと適切にする必要があるという兆候です。 UserではなくViewUser/EditUserです。

検索結果とリストには、IEnumerableの代わりにIEnumerableなどの情報を抽出するのが最善の方法です。後者は、プロジェクト全体で必要となるかもしれないし、必要でないかもしれないすべてのユーザープロパティのためのダンピング場になるユーザービューモデルクラスで終わることを意味します。これは注目すべき大きなものの1つで、このようなクラスで自分自身を見つけたら、あなたはどこかのトラックに行きました。あなたの意見を保持し、モデルを説明的で具体的なものにする。類似したビューモデルが多数ある場合は、おそらく問題が大きくなります。既存のグラフィカルな構造を再利用するのではなく、再考する傾向があります。