Должны ли модели просмотра в ASP.Net MVC быть строками?

Question

Я дошел до того (непреднамеренно), что чувствую, что в некоторых частях я делаю слишком много в самом представлении (.aspx), слишком много форматирования, объединения, в одном месте немного заменяет регулярное выражение.

Я начинал работать над новой частью и пытался улучшить свой подход. Затем меня поразило, почему бы мне просто не сделать все мои строки View Models (в / Models / in .Web project) или список строка в толчке. Примечание. Я имею в виду не мою модель / домен, а конкретную модель ViewModel.

public class FinanceQuoteView
{
    public string Provider; 
    public string Broker; // rather than Broker == null ? "N/A" : Broker.ToUpperCase();
    public string Monthly; // rather than Monthly.ToString("C")
    public string PaymentTerm; // rather than "1+" + PaymentTerm.ToString();
    public string FreeInsurance; // rather than insuranceIncluded ? "Yes" : "No";
    public string[] Restrictions;
}

Для отправки формы (добавление редактирования) я использую отдельную модель представления для подачи действия контроллера (модель формы, если хотите, в / Models / Form). Таким образом, FinanceQuoteForm содержит двойные числа и т. Д., Построенные через связыватель.

Что все думают об этом подходе? Делает ли .ToString ("C") в отображении из домена слишком много для просмотра модели?

Answer 1

Ваша модель должна выдавать правильные данные, тогда это зависит от представления, чтобы произвести данные в требуемом формате. Если вы построили другое представление поверх модели, вам может потребоваться выполнить различные манипуляции с данными, поэтому я предлагаю НЕ , возвращая их как строки из модели.

Answer 2

Согласен, в основном. Для традиционных форм редактирования я предпочитаю иметь отдельные модели для «модели поста» (передается в контроллер) и для просмотра / редактирования «модели представления» (передается в представление).

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

Пост-модель передает действие моего контроллера, которое затем определяет, какие команды выполнить, если таковые имеются.

Оттуда, если действие контроллера приводит к просмотру страницы просмотра / редактирования, тогда я создаю модель представления соответствующим образом и предоставляю ее представлению.

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

Супер чистый, и дает мне полный контроль над всем.

Answer 3

Я склонен довольно сильно наклоняться к струнам для моделей, которые я проектирую. В конце концов, большая часть данных, отображаемых в представлении, принимает форму строк. Каждый раз, когда я собираюсь выполнить манипулирование данными в представлении (.aspx / .ascx), я серьезно подумываю перенести эту логику в мою модель представления, чтобы я мог выполнить ее модульное тестирование. В конце концов, тестируемость - это главное преимущество, которое вы получаете от MVC, так почему бы не использовать его?

В WPF (просто для краткого обхода) многие элементы управления изначально понимают другие типы данных (например, числа, логические значения и т. Д.), Но на платформе, которая по своей природе связана со строками, такими как HTML, это делает для меня большой смысл рассматривать большую часть вывода как текст.

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

Я определенно не думаю, что это слишком много - я только думаю, что вы можете сделать это слишком мало:)

Answer 4

Ваша ситуация выглядит особенной и ограниченной в некотором смысле: ваша ViewModel либо для редактирования, либо для отображения. Большинство видов делают и то, и другое: у них много отображаемых и редактируемых материалов. Скажем, эта страница:

Показать вопрос, ответы и заметки. Редактировать: Ответить.

Я бы не хотел различать 2. Это закончилось бы дублированием множества полей отображения.

Я бы предпочел иметь одно представление с возможно двумя свойствами: одно для отображения и одно для значения формы.