我有一个实例，其中我使用模型上的接口来过滤列表的块和页面（即，使用“ IMyInterface”选择所有块或页面），但与此同时需要转换转换为另一种类型进行显示（即列出所有块/页面，然后将每个块/页面转换为“ MyDisplayType”并传递到局部视图）
我的问题：不鼓励我的EPiServer页面和块（我的模型）中的逻辑吗？
编辑以响应@Ted： PageViewModel上的属性将不起作用，attribute ==“ include me”，其他行为会执行“ included”（这就是我所说的过滤），并且由于我在模型上有一个接口，因此很自然我也要具有与模型中的属性相关联的逻辑（因为属性位于模型中）。如果我的类中没有具有该属性的逻辑，那么我需要一个“助手类”来托管我认为最好留在模型中的代码。
答案 0 :(得分：1)
也许我误解了这个问题，但是我想说，更常见的方法是拥有特定的视图模型类型。
因此，您的视图将具有max.poll.records = 2147483647，而不仅仅是@model IPageViewModel<SomePageType>。
然后在您的控制器中，您将使用@model SomePageType而不是return View(new SomePageViewModel(currentPage))。
相同的原则适用于其他内容类型（块，媒体等）。
除了诸如return View(currentPage)之类的特定方法之外，我将远离内容类型本身的逻辑。
在您的特定情况下，听起来您应该将内容列表作为属性添加到最初传递的视图模型实例中，然后在视图中枚举该属性以使用局部视图来呈现每个项目？
编辑：我认为界面非常适合“分组”内容类型，例如，获取所有SetDefaultValues页，无论确切的内容类型如何。我通常会在存储库类或控制器操作方法中放置用于检索内容集合（例如IArticle）的逻辑。当然，这种逻辑除了按接口过滤外，还可以反映属性。