ASP.Net MVC - Является ли этот уровень сущности слишком далеко?

Question

У меня есть модель данных домена, которая возвращает класс, такой как:

public class ZombieDeath
{
    public virtual int ZombieId {get;set;}
    public virtual FatalHit {get;set;}
}

public class FatalHit
{
    public virtual int HitId {get;set;}
    public virtual string Zone {get;set;}
    public virtual string Weapon {get;set;}    
}

При передаче этих данных обратно в мои таблицы я прочитал, что лучше всегда возвращать данные представлениямв плоском формате.Итак, у меня есть следующий класс, который представляет строку сетки:

public class ZombieDeathRow
{
    public virtual int ZombieId {get;set;}
    public virtual int HitId {get;set;}
    public virtual string Zone {get;set;}
    public virtual string Weapon {get;set;}
}

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

Это действительно хороший способ работы или просто трата времени?

Answer 1

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

Уровень домена предназначен для предоставления представления домена приложения независимо от используемого вами пользовательского интерфейса.

Модель на уровне представления может отличаться в зависимости от используемой технологии интерфейса пользователя.вы используете или какой клиент используется.Например, модель на уровне представления может выглядеть иначе для MVC, чем для WebForms (и некоторые люди используют оба параллельно).Модель на уровне представления для мобильного устройства может отличаться от модели для браузера, работающего на рабочем столе.Веб-сервис может использовать еще одну модель для эффективной передачи данных.Если вы используете AJAX в своем веб-приложении, вы можете предпочесть еще одну модель для эффективной передачи информации, например, с помощью JSON.

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

Answer 2

пустая трата времени ИМО.Вы будете тратить слишком много времени на написание кода сопоставления на что угодно, кроме самых простых решений.

Где вы читали, что лучше сплющить вашу ViewModel?Сложный бизнес-объект, представленный как свойство в ViewModel, может не поддерживать полностью инкапсулированный код, но по моему опыту с проектами MVC хорошая модель предметной области означает, что это не будет проблемой, за исключением пуристов.

Answer 3

Вы просматриваете структуру реляционных данных, которую лучше всего сохранять в 3-й нормальной форме.Из этого кода я не понимаю, почему нужно отделять FatalHit от ZombieDeath.Потеряет ли он 3-ю нормальную форму, если объединить их в одном классе?Есть ли в других классах FatalHit члены?

Если для представления этих данных требуются 2 отдельных класса, а третий, комбинированный класс используется только для упрощения работы в представлении, я не вижув третьем классе.