在MVVM架构中，特别是Model层;当Collection<BasicModelType>使用了完整的继承/实现BasicModelType的对象时;如何处理集合中“模型”的任何业务逻辑而不必在“模型”本身中实现业务逻辑的一部分？ （假设“as”和“is”使用是不允许的，因为它是糟糕的OOP练习）。
---如果上述情况不完全清楚，请在下面进一步说明.---
“模型”是指仅具有属性的基本类。
ViewModel通过XMLService获取模型。
XMLService只是一个知道如何根据XML文档中的内容创建模型的类。 （这只是为了说明如何创建模型）
OutputService是一个知道如何使用模型根据模型中的内容从软件创建输出的类。除了模型之外，它还有其他逻辑。
该模型包含其他ChildrenModel的集合。 ChildrenModel具有多态性，因为它们来自BaseModel。具有BaseModel是合乎需要的，因为它允许将它们存储并作为连续集合呈现给用户。下面的例子，道歉，因为这是我能想到的最简单的例子。
Truck : Vehicle
Name
HasTrailer
Car : Vehicle
Name
HasSpoiler
OutputService中定义的逻辑需要做不同的事情，具体取决于给定Model的Collection中的ChildModel是Truck还是Car。问题是，当然，ChildCollection属于基类类型Vehicle。知道实际类型的唯一时间是在ChildModel对象的实例化期间（并且因为XML中的类型是特定的，所以它是已知的）。
是否有一个通用模式来处理OutputService如何将其任何功能应用于ChildModel集合。根据定义，它需要知道每种模型类型。
使用switch语句检查类型（使用as或is）似乎完全错误。
当然，解决方案是在实际的ChildModel中包含“OutputService”中的逻辑;只是公开在BaseClass或Interface中执行该逻辑的函数。然后任何对象/服务/ veiwmodel可以遍历列表调用所述函数获取模型特定结果。但这不是基本上将业务逻辑拆分了吗？到处都没有“担忧”吗？
答案 0 :(得分：1)
如果您阅读The MVVM Pattern。
查看
视图负责定义结构，布局和 用户在屏幕上看到的内容。理想情况下，观点是 完全由XAML定义，但有限的代码隐藏却没有 包含业务逻辑。
<强>模型
MVVM中的模型是应用程序域的实现 包含数据模型以及业务和验证的模型 逻辑。模型对象的示例包括存储库，业务 对象，数据传输对象（DTO），普通旧CLR对象（POCO）， 并生成实体和代理对象。
查看模型
视图模型充当视图和模型之间的中介， 并负责处理视图逻辑。通常，视图 model通过调用模型中的方法与模型交互 类。然后，视图模型以表单形式提供模型中的数据 该视图可以轻松使用。视图模型从中检索数据 模型，然后使数据可用于视图，并可能重新格式化 以某种方式使数据更容易处理视图。该 view model还提供了用户的命令实现 应用程序在视图中启动。例如，当用户点击时 UI中的按钮，该操作可以在视图中触发命令 模型。视图模型也可以负责定义逻辑 状态更改会影响视图中显示的某些方面，例如 表示某些操作正在等待。
因此，我们可以看到您应该使用子类拆分业务逻辑。摘要根据孩子创建输出的逻辑。如果您对您的OOP设计有疑问，请考虑哪个更易于维护。请参阅SOLID (object-oriented design)。