Используя MVC, как мне спроектировать представление так, чтобы оно не требовало знания переменных, устанавливаемых контроллером? - PullRequest
0 голосов
/ 02 сентября 2011

Допустим, у меня есть теоретическая структура MVC, которая использует объект ViewData для передачи данных из контроллера в представление.В моем контроллере, скажем, у меня есть такой код (в псевдокоде):

function GetClientInfo()
{
    // grab a bunch of data from the database
    var client = Database.GetClient();
    var clientOrders = Database.GetClientOrders();
    var clientWishList = Database.GetClientWishList();

    // set a bunch of variables in the ViewData object
    ViewData.set("client", client);
    ViewData.set("clientOrders", clientOrders);
    ViewData.set("clientWishList", clientWishList);

    showView("ClientHomePage");
}

А затем в моем представлении ClientHomePage я отображаю данные следующим образом:

<p>Welcome back, [ViewData.get("client").FirstName]!</p>

<p>Your order history:</p>
<ul>
    [Html.ToList(ViewData.get("clientOrders")]
</ul>

<p>Your wishlist:</p>
<ul>
    [Html.ToList(ViewData.get("clientWishList")]
</ul>

Это то, на что я понимаю MVC (пожалуйста, поправьте меня, если я ошибаюсь).Проблема, с которой я столкнулся, заключается в том, что эти волшебные нити в поле зрения.Как представление узнает, какие объекты оно может извлечь из объекта ViewData, если оно не знает, что контроллер помещает туда в первую очередь?Что если кто-то выполнит рефакторинг одной из магических строк в контроллере, но забудет изменить ее в представлении и получит ошибку времени выполнения вместо ошибки времени компиляции?Это кажется мне довольно серьезным нарушением разделения интересов.

Здесь я думаю, что ViewModel может пригодиться:

class ClientInfo
{
    Client client;
    List clientOrders;
    List clientWishList;
}

Затем контроллер создает экземплярClientInfo и передает его на просмотр.ViewModel становится обязательным контрактом между контроллером и представлением, и представлению не нужно знать, что делает контроллер, если предполагается, что контроллер заполняет ViewModel должным образом.Сначала я думал, что это MVVM, но читая больше об этом, мне кажется, что я имею в виду больше MVC-VM, поскольку в MVVM контроллер не существует.

Мой вопрос заключается в том, чтоя не понимаю здесь о MVC против MVVM?Неужели обращение к переменным в ViewData по волшебным строкам не так уж плохо?И как можно гарантировать, что изменения, внесенные в контроллер, не окажут отрицательного влияния на представление?

Ответы [ 3 ]

2 голосов
/ 02 сентября 2011

Ваше понимание MVC неверно, оно обозначает Model View Controller, но вы упускаете модель в своем примере. Это типизированный объект, который передается обратно в представление для визуализации. В ASP.Net MVC вы должны использовать типизированные представления, которые также вводят модель в представлении, чтобы она проверялась во время компиляции. Это устраняет необходимость в магических строках (вторая часть вашего вопроса).

В MVVM у вас есть модель View ViewModel. Это способ привязки ViewModel непосредственно к слою пользовательского интерфейса через View, который часто используется в WPF. Он заменяет необходимость в контроллере, и это, как правило, отображение 1-к-1 с пользовательским интерфейсом. Это просто альтернативный механизм, который решает ту же проблему (абстрагирования и разделения проблем), но лучше подходит для технологии.

Здесь есть некоторая полезная информация здесь , которая может помочь понять разницу.

2 голосов
/ 02 сентября 2011

Лучший подход к использованию строго типизированных представлений

Модель:

public class ContentPage
{
    public string Title { get; set; }
    public string Description { get; set; }
}

public class ContentPagesModel
{
    public ContentPage GetAboutPage()
    {
        var page = new ContentPage();
        page.Title = "About us";
        page.Description = "This page introduces us";

        return page;
    }
}

Контроллер:

public ActionResult About()
{
    var model = new ContentPagesModel();
    var page = model.GetAboutPage();

    return View(page);
}

Вид:

@model Experiments.AspNetMvc3NewFeatures.Razor.Models.ContentPage
@{
    View.Title = Model.Title;
} 

<h2>About</h2>
<p>
     @Model.Description
</p>

для более подробной информации проверьте здесь

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

0 голосов
/ 02 сентября 2011

Похоже, ваше понимание MVC очень старое, вероятно, основанное на MVC 1. За последние пару лет все сильно изменилось.

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

Более того, мы больше не передаем данные модели через ViewDate (ну, во всяком случае, напрямую, в любом случае… они все еще проходят этот путь, но фреймворк скрывает это).

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...