ベストプラクティスとは何か知りたいです。私は常に ViewModel を作成し、データをビューに渡すためにコア Model クラスを使用しないように言われました。それは理にかなっている。物事を分けてみましょう。しかし、Model とは ViewModel とまったく同じです。別のクラスを再作成するか、それを使用する必要があります。
作り直した方がいいと思います。専門家の言うことを知りたいだけ..
ベストプラクティスとは何か知りたいです。私は常に ViewModel を作成し、データをビューに渡すためにコア Model クラスを使用しないように言われました。それは理にかなっている。物事を分けてみましょう。しかし、Model とは ViewModel とまったく同じです。別のクラスを再作成するか、それを使用する必要があります。
作り直した方がいいと思います。専門家の言うことを知りたいだけ..
ドメイン エンティティと同一であっても、別のビュー モデルを必ず作成する必要があります。ビュー モデルとドメイン エンティティは完全に独立している必要があります。つまり、一方を変更しても、他方が変更を認識したり気にしたりする必要はありません。ビュー モデルはビューを表す必要があり、ドメイン エンティティは...まあ...ドメイン エンティティを表す必要があります。それらは現在同一である可能性がありますが、いずれかが変更された場合、一方の変更が他方に影響を与えることはありません。
ドメイン モデルが突然変更され、ビュー モデルに関連しなくなったフィールドがある場合はどうなるでしょうか? それらが分離されていない場合は、問題があります。さらに悪いことに (そしておそらくより可能性が高い)、ビュー モデルがまったく別のエンティティからのより多くの情報を突然必要とした場合はどうなるでしょうか? ビューでアクセスできるようにするためだけに、このまったく無関係な情報でドメイン モデル内のクラスのカプセル化を破るつもりですか?
ソリューションを分離して柔軟に保ちます。ビュー モデルを使用します。
ちなみに、ModelView を作成することをお勧めします。したがって、この特定のケースでは同じであり、データが送信される UI とモデルの間の「ブリッジ」のように機能します。
ただし、スケーラビリティには適しています。ビュー モデルに固有の UI を追加する可能性が非常に高いため、モデル自体からますます延期されます。
したがって、一般的なアドバイス:ちなみに、それらが同じであっても作成してください。後で必要になったときにスケーリングするのに役立ちます。
しかし、Model とは ViewModel とまったく同じです。別のクラスを再作成するか、それを使用する必要があります。
もちろん、まったく同じであれば、ビューモデルは必要ありません。しかし、それはかなりまれな状況です。