モデル（親）に多態性モデル（子）のコレクションが含まれている場合のビジネスロジック

Question

MVVMアーキテクチャでは、具体的にはモデルレイヤーです。 Collection<BasicModelType>が継承/実装するオブジェクトでいっぱいに使用されている場合BasicModelType; 「モデル」自体にビジネスロジックの一部を実装することなく、コレクション内の「モデル」上のビジネスロジックをどのように処理するのでしょうか？ （OOPの貧弱な実践であるため、「as」と「is」の使用は許可されていないと仮定します）。

は---上記全く明確でない場合は、以下にさらに説明.---

「モデル」だけのプロパティを持つ基本的なクラスを意味します。

ViewModelは、XMLServiceを介してモデルを取得します。

XMLServiceは、XMLドキュメント内のモデルからモデルを作成する方法を知っている単なるクラスです。 （モデルの作成方法を教えてください）

OutputServiceは、モデルを使用して、モデルの内容に基づいてソフトウェアから出力を作成する方法を知っているクラスです。それはまた、モデルだけで必要なもの以外のロジックも持っています。

モデルには他のChildrenModelsのコレクションが含まれています。 ChildrenModelはBaseModelから来ている点で多型です。 BaseModelを持つことは、連続したコレクションとしてユーザーに格納して提示できるため、望ましいことです。以下の例は、私が考えることができる最も単純な例であるので、お詫び申し上げます。 OutputServiceで定義された

Truck : Vehicle 
    Name 
    HasTrailer 

Car : Vehicle 
    Name 
    HasSpoiler 

LogicはChildModelが与えられたモデルのコレクションにトラックや車である場合に応じて異なることを行う必要があります。問題はもちろん、ChildCollectionは基底クラスタイプVehicleです。実際の型がわかっている唯一の時間は、ChildModelオブジェクトのインスタンス化中です（XMLの型が固有であるために認識されます）。

OutputServiceがどのようにその機能をChildModelコレクションに適用するかを処理する共通のパターンがありますか？定義上、各モデルタイプを知る必要があります。

switch文で型をチェックするのは間違っているようです。

もちろん、実際のChildModelに "OutputService"のロジックを含めることが解決策です。そのロジックを実行した関数をBaseClassまたはInterfaceに公開するだけです。次に、任意のオブジェクト/サービス/仮想モデルが、モデル固有の結果を得る前記関数を呼び出すリストを反復するだけでよい。しかし、これは基本的にビジネスロジックを分割していませんか？ 「懸念」はどこにでも振りかざされていませんか？

Answer 1

The MVVM Patternと書いてあります。

ビュー

ビューは、ユーザが画面上で見るものの構造、レイアウト、および 外観を定義する責任があります。理想的には、ビューは で、XAMLでのみ定義され、ビジネスロジックを含む のコードビハインドは限定されています。

モデル

MVVMでのモデルは、ビジネスと検証 ロジックと一緒にデータモデルを含むアプリケーションのドメイン モデルの実装です。モデルオブジェクトの例には、リポジトリ、ビジネス オブジェクト、データ転送オブジェクト（DTO）、プレイン旧CLRオブジェクト（POCO）、 、生成されたエンティティおよびプロキシオブジェクトが含まれます。

ビューモデル

は、ビューモデルは、ビューとモデルの間の仲介役として機能 と表示ロジックを処理する責任があります。通常、ビュー モデルは、モデル クラスのメソッドを呼び出すことによってモデルと対話します。次に、ビューモデルは、ビューから容易に使用できる形式のモデル のデータを提供します。ビューモデルは、 モデルからデータを取得し、そのデータをビューで使用できるようにします。ビューを処理するためにデータを何らかの形で再フォーマットすることができます。 ビューモデルは、アプリケーションがビュー内で開始する のユーザーが実行するコマンドの実装も提供します。たとえば、ユーザーがUIのボタン をクリックすると、そのアクションはビュー モデルのコマンドをトリガーできます。ビューモデルは、ビュー内のディスプレイの一部のアスペクトに影響を及ぼす論理的な 状態の変更を定義する責任もあります。 などの操作が保留中であることを示します。

これから、ビジネスロジックを子クラスを使用して分割する必要があることがわかります。子に応じて出力を作成するロジックを抽象化します。あなたのOOPデザインに疑問がある場合は、どちらがより保守的かを考えてください。 SOLID (object-oriented design)を参照してください。