Когда использовать строго типизированные представления?

Question

Я работаю над приложением MVC, и мне интересно, в какой ситуации лучше использовать строго типизированное представление, а когда нет ... Думаю, это скорее вопрос передового опыта. Я делаю приложение для электронной коммерции, и есть таблица заказов, продуктов и т. Д. Часть, над которой я работал, подтолкнула меня к этому вопросу, заключалась в том, что я добавил страницу нового продукта для администраторов, чтобы добавить больше элементов магазина. когда будет полезно использовать строго типизированное представление.

Я уже искал похожие вопросы и ничего не появилось на первых трех страницах или около того, но, если вам известно о посте, направьте меня.

Спасибо.

Answer 1

В любое время, когда вам нужно отобразить данные (по любому конкретному объекту или коллекции объектов) в представлении, используйте строго типизированное представление.

Если ваше представление носит исключительно информационный характер, вы можете использовать ModelState для передачи небольших битов информации (например, страниц об успехе / ошибке, неавторизованных сообщениях и т. Д.)

В моих приложениях у КАЖДОГО представления строго типизированный вид, так что я могу легко передавать информацию о входе пользователя на главную страницу. То есть все мои представления строго типизированы, шаблонизированы и ограничены базовым классом, который содержит конфигурацию сайта и информацию для входа пользователя.

Из-за этого я могу сделать это:

public class MyBaseMasterPage : ViewMasterPage<MyBaseModel>
{
    public string CurrentTheme
    {
        get
        {
            if (this.Model.CurrentUser != null)
                return this.Model.CurrentUser.Theme;

            else return this.Model.Config.DefaultTheme;
        }
    }

    public User CurrentUser { get { return this.Model.CurrentUser; } }

    public ConfigurationRepository Config { get { return this.Model.Config; } }
}

Обратите внимание, что, поскольку главная страница имеет тематическую структуру, основанную ТОЛЬКО на том, что заполнено в модели, само представление никогда не вызовет попадание в базу данных / кэш.

MyBaseModel настроен так:

public class MyBaseModel
{
    private MyBaseModel() { }

    public MyBaseModel(MyBaseController controller)
    {
        this.CurrentUser = controller.CurrentUser;
        this.Config = controller.Config;
    }

    public User CurrentUser { get; private set; }

    public ConfigurationRepository Config { get; private set; }
}

Закрытый конструктор заставляет все подклассы моей модели инициализировать модель с помощью контроллера soruce.

Базовый класс контроллера выводит пользователя из сеанса, а Config из кэша.

Таким образом, несмотря ни на что, все мои представления имеют доступ к пользовательским данным и данным конфигурации, даже не создавая попадания в БД.

Теперь в MyBaseController:

public class LanLordzBaseController : Controller
{
    [Obsolete]
    protected new ViewResult View(string viewName, object model)
    {
        if (model == null)
        {
            throw new ArgumentNullException("model");
        }

        if (!(model is MyBaseModel))
        {
            throw new ArgumentException("The model you passed is not a valid model.", "model");
        }

        return base.View(viewName, model);
    }

    protected ViewResult View(string viewName, MyBaseModelmodel)
    {
        if (model == null)
        {
            throw new ArgumentNullException("model");
        }

        return base.View(viewName, (object)model);
    }

    public ConfigurationRepository Config { get { ... } }

    public User CurrentUser { get { ... } }
}

Это помогло мне найти все мои контроллеры, которые возвращали представления, которые не были унаследованы от надлежащего базового класса.

Answer 2

Если есть данные, должно быть строго типизированное представление. Период.

Answer 3

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

Я создаю свои строго типизированные представления в любое время, когда мне нужна информация из более чем одного источника для представления.

Например, при оформлении заказа мне требуется заказ, а также пользовательские настройки для отображения цены; поэтому я создал CheckoutViewModel, у которого есть свойства Order и PriceDisplay.

Надеюсь, это поможет,

Dan

Answer 4

Всегда. Я бы пошел дальше и использовал строго типизированные элементы управления и действия HtmlHelper. Большинство из них доступны в библиотеке MvcContrib .

Answer 5

Хотя я повторяю то, что красноречиво заявили другие, я думаю, что есть еще один момент для поднятия. Представление является частью концепции Модель, Представление, Контроллер и, как таковое, должно представлять Модель визуально для пользователя. Учитывая, что это, по сути, представление модели, имеет смысл, чтобы она была строго типизирована.

Я всегда использую ModelState или TempState только для передачи небольших фрагментов данных, таких как сообщения о результатах таких действий, как добавление, удаление и т. Д. Каждый раз, когда возникает желание использовать State для передачи коллекций, не связанных с типом View, я преобразовать эту функциональность в частичное представление и представить это с помощью отдельного действия контроллера.

В моем коде связанные типы обычно ссылаются иерархически из базового типа, для которого представление строго типизировано, и поэтому доступны в представлении при необходимости.

Answer 6

Строго типизированное представление лучше всего использовать при изменении экземпляра этого типа в представлении.

Например, когда вы редактируете или создаете Продукт в представлении, было бы целесообразно иметь строго типизированное представление для класса продукта.

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

Все это произойдет довольно естественно, так как вы больше работаете с MVC, по моему опыту.