1つの顧客エンティティに対して、Create、Update、Get、Deleteなどの既存のビューに応じて複数のビューモデルがあります。これらのビューモデルは、エンティティと最大75%同じプロパティを共有します。
すべての顧客ビューモデルを1つの大きなビューモデルにマージする方がよいでしょうか?
だから私は常に1つのエンティティから1つのビューモデルにマップする必要がありますか?私が今考えていない特定のシナリオの柔軟性に不利な点はありますか?
1つの顧客エンティティに対して、Create、Update、Get、Deleteなどの既存のビューに応じて複数のビューモデルがあります。これらのビューモデルは、エンティティと最大75%同じプロパティを共有します。
すべての顧客ビューモデルを1つの大きなビューモデルにマージする方がよいでしょうか?
だから私は常に1つのエンティティから1つのビューモデルにマップする必要がありますか?私が今考えていない特定のシナリオの柔軟性に不利な点はありますか?
長期的には、各ViewModelに含まれるデータは類似している場合もあれば同一である場合もありますが、意図が異なるため、それらを分離しておく方が適切です。たとえば、ViewModelの作成と更新は確かに似ていますが、いくつかの重要な違いがあります。まず、ビューモデルの作成には通常、エンティティのIDがなく、それが意味をなさないため、混乱する可能性があります。次に、アプリケーションが部分的な更新をサポートしている場合、更新ViewModelは、エンティティ全体ではなく、既存のエンティティに対する変更のコレクションである可能性があります。
DRYを目指している場合は、ViewModelクラス全体を共有する以外の方法で再利用性を実現できます。代わりに、より小さな再利用可能なコンポーネントを作成し、継承の代わりにコンポジションごとに再利用できます。すべての要件を満たすために単一のViewModelクラスを強制しようとすると、コードの推論がより困難になるため、バグが発生します。多くの場合、単純なコピー&ペーストは、OOPが提供するものよりもうまく機能します。
一方では、説明するときにViewModelを分割すると、コードベースが非常に明確になります。これは、各ViewModelが目的に正確に適合し、不要なプロパティがないことを確認できるためです。一方、それは維持するコードが多いことを意味します-エンティティへの変更は、いくつかのViewModelへの変更を意味する可能性があります。
一方、1つの大きなViewModelアプローチには、基本的に正反対の長所と短所があります。維持するコードは少なくなりますが、ViewModelsは目的にあまり適合しません。
ここには本当に正しい答えも間違った答えもありません。それぞれのアプローチの長所と短所を比較検討し、自分に最適な方法を決定する必要があります。
中途半端なアプローチの1つは、作成/更新用に1つ、取得用に1つ、削除用に1つのViewModelを用意することです。これは、作成/更新が非常に似ている可能性が高いためです。
もう1つの最もOOなオプションは、古き良き継承にあります。1つのクラスのアクション間で共通の機能を定義し、MyVM
さまざまなアクションに適していると思われるように拡張(継承)します:MyVMEdit
、、、`MyVMList'。MyVMDelete
MyVMCreate
これは両方の長所です。1回だけ保守し、すべてのビューに正確に適合するように拡張します。
ここには正しいアプローチはありません。数学ではないので、仕事を成し遂げるアプローチはどれも仕事を成し遂げます:)しかし...時々私たちはルーツから離れすぎてしまいました:)純粋な古き良きオブジェクト指向アプローチ。
継承(または拡張)によって問題が発生した場合(何らかの理由で)、MyVM
すべてのモデル内に部分を埋め込んMyVM<Action>
で、同じレベルの抽象化/機能のバランスを実現できます。
いつものように-適切な仕事のための適切なツール。
これがお役に立てば幸いです。