Логика внутри страниц и блоков EPiServer

Question

У меня есть экземпляр, где я использую интерфейс в моей модели в качестве средства фильтрации моих блоков и страниц для списков (то есть выбираю все блоки или страницы с помощью «IMyInterface»), но наряду с этим требуется преобразование для отображения другого типа (т. е. перечислить все блоки / страницы, затем для каждого блока / страницы преобразовать в «MyDisplayType» и перейти к частичному просмотру)

Мой вопрос: не поощряется ли логика внутри моих страниц и блоков EPiServer (мои модели)?

Изменить в ответ на @Ted: Атрибут в PageViewModel не будет работать, атрибут == «включить меня», что-то еще делает «акт включения» (именно это я и имел в виду под фильтрацией), и, поскольку у меня есть интерфейс в моей модели, естественно Мне бы иметь логику, связанную с атрибутом в модели, а также (как атрибут на модели). Если в моем классе нет логики с атрибутом, мне нужен «вспомогательный класс» для размещения кода, который, по моему мнению, лучше всего оставить в модели.

Answer 1

Возможно, я неправильно понимаю вопрос, но я бы сказал, что более распространенный подход - иметь конкретные типы моделей представлений.

Итак, ваши просмотры будут иметь @model IPageViewModel<SomePageType> вместо @model SomePageType.

В вашем контроллере вы бы return View(new SomePageViewModel(currentPage)) вместо return View(currentPage).

Тот же принцип применим к другим типам контента (блоки, медиа и т. Д.).

Я бы держался подальше от логики в самих типах контента, за исключением особых методов, таких как SetDefaultValues.

В вашем конкретном случае это звучит так, как будто вы должны добавить список содержимого в качестве свойства к экземпляру модели представления, который был первоначально передан, а затем перечислить это свойство в представлении, чтобы отобразить каждый элемент с использованием частичного представления?

Редактировать: Я думаю, что интерфейсы отлично работают для "группировки" типов контента, например, для получения всех IArticle страниц, независимо от точного типа контента. Я обычно помещаю логику для извлечения коллекций контента (например, all article pages) в классы репозитория или методы действия контроллера. Конечно, такая логика, помимо фильтрации по интерфейсу, может также отражать атрибуты.