Когда использовать модель представления в ASP.NET MVC?

Question

Представьте себе движок блога в ASP.NET MVC, где я хочу строго типизированные представления. У меня есть модель для BlogPost и модель для комментариев. Типичная страница будет отображать сообщение в блоге и все комментарии этого сообщения. Какой объект я должен передать в View ()? Должен ли я создать модель презентации? Может быть, я неправильно использую этот термин, но я имею в виду, должен ли я создать составную модель только для View (), что-то вроде BlogAndComments? Должен ли мой контроллер создать экземпляр BlogAndComments и что это?

Или я должен как-то передать объекты BlogPost и Comments в View?

Answer 1

Я думаю, вы на правильном пути со своим пониманием презентационных моделей. Что касается того, когда вы должны создать модель представления, ответ, вероятно, «это зависит». В вашем примере вы, вероятно, можете сойти с передачей BlogPost и Comments в объекте ViewData. Это не великолепно, но эй, это делает работу.

Когда и если это начинает казаться уродливым или громоздким, тогда я начинаю думать о создании модели представления. Я обычно заканчиваю понятием «Страница», которое включает в себя заголовок страницы, общие данные, а затем конкретный материал для конкретной страницы. В вашем случае это может закончиться как BlogViewPage, который включает в себя комментарии Title, BlogPost и List.

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

Answer 2

Я всегда использую строго типизированные представления и создаю класс модели представления для каждого представления или пользовательского элемента управления представления. Преимущество состоит в том, что, глядя на один только класс модели представления, я точно знаю, какие значения использует представление. Если бы я передавал доменные модели, это было бы неочевидно, потому что доменные модели могут содержать много свойств, которые представление не использует. Мне бы пришлось посмотреть на разметку представления, чтобы выяснить, какие значения ему нужны. Кроме того, модель представления обычно добавляет определенные свойства, которые недоступны в модели предметной области. Это кажется немного утомительным, но я думаю, что это экономит время и делает код лучше в долгосрочной перспективе.

Answer 3

По моему мнению, комментарии относятся к мнению так же, как и к самому посту.

Создайте класс BL для ваших комментариев, например:

class CommentBO
{
    Guid UserID;
    string Text;
}

Тогда у вас есть БО для вашего поста.

class PostBO
{
    Guid UserID;
    List<CommentBO> Comments;
}

Тогда ваша модель может быть очень простой.

class BlogModel
{
    string AuthorName;
    string BlogTitle;

    List<PostBO> Posts;
}

Передайте его представлению и визуализируйте.

У вас может возникнуть желание опустить все BO и просто заполнить модель непосредственно из базы данных. Это вариант, но не совсем правильный. Модель - это просто набор вещей для отображения. Эти вещи, однако, должны быть подготовлены где-то еще, а именно на уровне бизнес-логики только с номинальным участием контроллера.

Answer 4

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