I have an instance where I'm using an interface on my Model as a means of filtering my blocks and pages for lists (i.e. select all blocks or pages with "IMyInterface"), but along with that is a requirement to convert to another type for display (i.e. list all blocks/pages, then for each block/page, convert to "MyDisplayType" and pass to a partial view)
My question: Is logic inside my EPiServer Pages and Blocks (my models) discouraged?
Edit in response to @Ted: An attribute on the PageViewModel won't work, attribute == "include me", something else does the "act of inclusion" (that is what I meant by filtering), and as I have an interface on my model, it's natural to me to have logic associated with the attribute in the model as well (as the attribute is on the model). If i don't have logic in my class that has the attribute, then I need a "helper class" to host the code that I feel is best left in the Model.
Perhaps I'm misunderstanding the question, but I would say the more common approach is to have specific view model types.
So, your views would have @model IPageViewModel<SomePageType> instead of just @model SomePageType.
In your controller you would then return View(new SomePageViewModel(currentPage)) instead of return View(currentPage).
Same principle applies to other content types (blocks, media, etc).
I would stay away from logic in the content types themselves, except for specific methods such as SetDefaultValues.
In your particular case it sounds like maybe you should add the content list as a property to the view model instance originally passed, and then enumerate that property in the view to render each item using a partial view?
Edit: I think interfaces work great for "grouping" content types, for example to get all IArticle pages, regardless of exact content type. I usually put logic for retrieving collections of content (e.g. all article pages) in repository classes or controller action methods. Of course such logic could, in addition to filtering by interface, also reflect attributes.