MVC в .NET: как не дублировать классы?
У меня есть класс Person в модели, и я хочу назначить 15 его атрибутов меткам в представлении. Представление не должно иметь доступа к модели. Это означает, что Контроллер будет обрабатывать создание Человека. Как представление получает эти атрибуты Person от контроллера? Если контроллер содержит член типа Person, View может делать что-то вроде:
lblFirstName.Text = theController.Person.FirstName;
lblLastName.Text = theController.Person.LastName;
lblCity.Text = theController.Person.City;
Однако представление по-прежнему напрямую обращается к модели (т. Е. К человеку). Контроллер может иметь свой собственный класс Person, копировать в него все атрибуты Person модели и иметь синтаксис использования View, как указано выше. Но в этом дизайне много дублирования. Какие-либо предложения?
Кстати, это в форме winform. Модель также представляет собой отдельный проект / DLL. Что такое DTO?
Атрибуты Person в модели имеют особую логику, с которой я не хотел, чтобы у View возникали проблемы. Например, View может делать:
строка fn = myController.Firstname;
И получите исключение из-за логики в свойстве FirstName. Таким образом, облегченная (дублированная) версия объекта Person Controller не будет иметь ни одной из этих проблем, поскольку ее свойства представляют собой только строки.
Также обратите внимание, что вашему представлению потребуется ссылка на модель для обработки скрытого свойства Person, поступающего от контроллера. Мне это не нравится.
Ответы 4
Человек может быть в view-data. Я лично не думаю, что существует огромная проблема с представлением, обращающимся к экземплярам типов моделей, которые контроллер уже получил, поэтому лично я бы позволил представлению видеть Person напрямую.
Может быть желательно сгладить модель в модель представления, если требуется множество глубоких свойств, таких как от person.Foo.Bar.Blip до obj.Blip в модели представления.
Если вы имеете дело с одним объектом, другой вариант - поместить каждое значение отдельно в словарь, но это немного беспорядочно.
Другой вариант - злоупотребление анонимными типами; но не делай этого! Я даже не буду здесь повторять подробности, это то самое бредовое; но вот это.
Вы можете разделить проблемы в своей модели, даже если вы используете классы DTO, которые являются объектами со свойствами или, если быть более строгим, конструктором и набором свойств, доступных только для чтения. Сначала это может показаться дублированием кода, но это становится действительно гибким способом обработки различных видов представлений и результатов, ожидаемых от вашей модели.
Я не уверен, почему вы не можете поделиться своей моделью на ваш взгляд. Нет необходимости в дублировании, и не похоже, что вам нужно использовать DTO, поэтому я просто передал бы Person в сумке состояния, и все будет хорошо.
Я думаю, вы больше думаете о своих услугах. Вы не хотите, чтобы ваше представление получало доступ к вашим службам, но ваш контроллер сделает его упаковку, а затем отправит в представление. Что касается простой модели, хотя на самом деле нет никаких препятствий для отправки этого через IMHO. Единственный другой способ - иметь модель в том же проекте, что и ваше представление, которая по сути была бы копией вашей модели, за исключением только значений, которые вы отправляете. В этом случае я мог бы увидеть выгоду, но опять же ... ваш пример не такой уж специализированный.
Немного не по теме (в MVC), но по теме вашей проблемы:
Почему бы не использовать менее громоздкое решение? Если вам нужно просто присвоить 15 меткам 15 значений, вы можете дать своему контроллеру проиндексированное свойство или метод, который использует имя времени разработки вашего объекта Label в качестве ключа для извлечения соответствующего значения из вашей модели с помощью словаря или отражения имен свойств вашей сущности или большой оператор переключения:
foreach(Control control in myLabelsPanel.Controls)
{
Label label = control as Label;
if (label != null)
{
label.Text = myController.TextForKey[label.Name];
}
}
Обновлено: я просто забыл добавить, что я не считаю плохим представление, обращающееся к классам объектов моей модели. В конце концов, они являются моделью, и они могут стать частью ViewModel (если вы используете эту парадигму), а MVC поощряет представление View, зная о модели (но не наоборот).