In MVVM architectures, specifically the Model layer; when a Collection<BasicModelType> is used full of objects that inherit/implement BasicModelType; how does one go about handling any business logic on the "Models" in the collection without having to implement a portion of the business logic in the "Models" themselves? (Assumption "as" and "is" usage is not allowed as it is poor OOP practice).
---Further Explanation below if above is not totally clear.---
"Model" means a basic class with just properties.
ViewModel gets the Model via a XMLService.
XMLService is just a class that knows how to create Models from what is in the XML document. (This is just to tell how the models got created)
OutputService is a class that knows how to use the Models to create an Output from the software based on what is in the Models. It also has other logic outside of what it needs to do with just the Models.
The Model includes a Collection of other ChildrenModels. The ChildrenModels are polymorphic in that they come from a BaseModel. Having a BaseModel is desirable as it allows them to be stored and presented to the user as a contiguous collection. Example below, apologies, as it is the simplest example I could think of.
Truck : Vehicle
Name
HasTrailer
Car : Vehicle
Name
HasSpoiler
The Logic defined in the OutputService would need to do different things depending on if the ChildModel in a given Model's Collection is a Truck or a Car. The issue is that of course, the ChildCollection is of the base class type Vehicle. The only time the actual type is known is during instantiation of the ChildModel object (and it is known because the type in the XML is specific).
Is there a common pattern to handle how the OutputService would apply any of its functionality to the ChildModel collection. It by definition would need to know each models type.
It seems COMPLETELY wrong to have switch statements checking the type (with as or is).
Of course a solution would be to include the logic from the "OutputService" in the actual ChildModel; just exposing the function that executed that logic in the BaseClass or an Interface. Then any object/service/veiwmodel could just iterate through the list calling said functions getting the Model specific results. But doesn't this essentially split the Business Logic up? Hasn't the "concerns" been sprinkled everywhere?
If you read The MVVM Pattern.
View
The view is responsible for defining the structure, layout, and appearance of what the user sees on the screen. Ideally, the view is defined purely with XAML, with a limited code-behind that does not contain business logic.
Model
The model in MVVM is an implementation of the application's domain model that includes a data model along with business and validation logic. Examples of model objects include repositories, business objects, data transfer objects (DTOs), Plain Old CLR Objects (POCOs), and generated entity and proxy objects.
View Model
The view model acts as an intermediary between the view and the model, and is responsible for handling the view logic. Typically, the view model interacts with the model by invoking methods in the model classes. The view model then provides data from the model in a form that the view can easily use. The view model retrieves data from the model and then makes the data available to the view, and may reformat the data in some way that makes it simpler for the view to handle. The view model also provides implementations of commands that a user of the application initiates in the view. For example, when a user clicks a button in the UI, that action can trigger a command in the view model. The view model may also be responsible for defining logical state changes that affect some aspect of the display in the view, such as an indication that some operation is pending.
So from this we can see that you should split the business logic up using the child classes. Abstract the logic of creating an output depending on the child. If you have doubts in your OOP design, think of which is more maintainable. See SOLID (object-oriented design).