MVC в .NET: Как не дублировать классы?

Question

У меня есть класс Person в модели, и я хочу назначить 15 его атрибутов меткам в представлении. Представление не должно обращаться к модели. Это означает, что контроллер будет обрабатывать создание человека. Как View получает эти атрибуты Person от контроллера? Если контроллер содержит член типа Person, представление может делать что-то вроде:

lblFirstName.Text = theController.Person.FirstName;

lblLastName.Text = theController.Person.LastName;

lblCity.Text = theController.Person.City;

Тем не менее, представление все еще имеет прямой доступ к модели (то есть персоне). Контроллер может иметь свой собственный класс Person, скопировать в него все атрибуты Person модели и использовать синтаксис View, как указано выше. Но в этом дизайне много дублирования. Есть предложения?

---

Кстати, это в форме win. Модель также является отдельным проектом / DLL. Что такое DTO?

Атрибуты Person в Модели имеют специальную логику, с которой я не хотел, чтобы у View возникали проблемы. Например, представление может сделать:

string fn = myController.Firstname;

И получить исключение из-за логики в свойстве FirstName. Таким образом, облегченная (дублирующаяся) версия объекта Person контроллера не будет иметь ни одной из этих проблем, поскольку его свойства являются только строками.

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

Answer 1

Немного не по теме (на 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 знать о модели (но не наоборот).

Answer 2

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

Answer 3

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

Я думаю, вы больше думаете о своих услугах. Вы не хотите, чтобы ваше представление получало доступ к вашим сервисам, но ваш контроллер выполнил бы его, а затем отправил в представление. Что касается просто простой модели, то, на самом деле, нет никакого недостатка в отправке этого через ИМХО. Единственным другим способом было бы иметь Модель в том же проекте, что и ваше представление, которое, по сути, будет копией вашей модели, за исключением тех значений, которые вы отправляете. В этом случае я мог видеть выгоду, но опять же ... ваш пример не настолько специализирован.

Answer 4

Человек может быть в view-data. Лично я не думаю, что существует огромная проблема с представлением доступа к экземплярам типов моделей, которые уже получены контроллером, поэтому лично Я бы позволил представлению увидеть Person напрямую.

Может быть желательно сгладить модель в модель представления, если требуется много глубоких свойств, например от person.Foo.Bar.Blip до obj.Blip в модели представления.

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

Другим вариантом является злоупотребление анонимными типами; но не делай этого! Я даже не буду повторять детали здесь, это то, что грязно; но здесь .