Неправильная практика иметь наследование от модели представления в Asp.net MVC?

Question

У меня есть ситуация, когда у меня есть куча общих свойств в модели представления, но есть определенные случаи, когда мне нужно ее расширять. Я создал пару странных моделей взглядов, которые я рассматриваю в представлениях, которые ожидают производную модель обзора. (Я понимаю, что я мог бы использовать Polymorphic Binder, но я доволен только проездом в производной модели представления на данный момент

код выглядит примерно так:.

public class CommmonViewModel 
{ 
    public int? CommonA{ get; set; } 
    public int? CommonB{ get; set; } 
    public int? CommonC{ get; set; } 
} 

public class SpecificViewModel1 : CommmonViewModel 
{ 
    public int? SpecificD{ get; set; }  
} 

public class SpecificViewModel2 : CommmonViewModel 
{ 
    public int? SpecificE{ get; set; }  
} 

код рецензент хочет, чтобы у меня три различные модели просматривать и дублировать код следующим образом:

public class SpecificViewModel1 
{ 
    public int? CommonA{ get; set; } 
    public int? CommonB{ get; set; } 
    public int? CommonC{ get; set; } 

    public int? SpecificD{ get; set; } 
} 

public class SpecificViewModel2 
{ 
    public int? CommonA{ get; set; } 
    public int? CommonB{ get; set; } 
    public int? CommonC{ get; set; } 

    public int? SpecificE{ get; set; } 
} 

Теперь имея в виду, что модели реальной жизни вид весьма немного более сложным, чем то, что я показал здесь, я ненавижу, что решение должно быть дублировать код, поскольку он чувствует себя довольно плохое нарушение o f СУХОЙ для меня.

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

Одним словом, он прав? это случай, когда я должен быть доволен дублированием кода? Каковы преимущества \ недостатки наследования в этом сценарии?

Спасибо за ваши мысли

Answer 1

Если все свойства базового базового класса используются на ваших формах/производных классах, то, на мой взгляд, проблем нет. Могут возникнуть проблемы с безопасностью, если у вас есть свойства модели просмотра, которые не используются в форме из-за атаки underposting/overposting.

Рассмотрите следующий сценарий. У вас есть класс пользователей в домене:

public class User 
{ 
    public string Username { get; set; } 
    public string Username { get; set; } 
    public bool IsAdmin { get; set; } 
} 

Теперь предположим, что ваш взгляд модель Войти просто наследует от модели домена, как это:

public class Login : User 
{ 
    // Whatever overrides you have... 
} 

Если пользователь каким-то образом знают о вашей модели домена архитектуре он может добавить скрытое поле на вашей странице входа, которая устанавливает свойство IsAdmin в значение true. Это то, что называется перенапряжением атаки. Это поле будет сопоставляться с вашей моделью, поскольку вы наследуете от пользователя и, возможно, сопоставляете свою модель домена и изменяете роль пользователя в базе данных.

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

Answer 2

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

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

Гораздо проще поддерживать сайт MVC, когда каждая модель уникальна для просмотра или частичного просмотра (или нескольких видов/частичных представлений).

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

Даже если вы не хотите использовать EntityFramework 6, вы можете использовать Micro ORM, например, Peta Poco, у которого есть шаблоны T4, которые могут автоматически генерировать все ваши Poco (Модели).

Как моя база данных sql имеет таблицы, в которых есть 3 общих столбца Sql (Active, Created, Update), все мои модели имеют свойства для «Active, Created and Updated», потому что я не писал свои модели, Peta Poco Did.

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

Теперь предположим, что я хочу добавить класс с ужасом для каждой модели, созданной PetaPoco. Я все еще могу это сделать. Я бы просто создал новый класс, а затем создал частичный класс для каждой модели pao pa, а Derrive - из моего класса в частичных.

Возможно, я смог изменить шаблон T4 для Peta Poco в моем проекте, чтобы добавить базовый класс к моделям, которые он генерирует.

Answer 3

Это потребует некоторого анализа и будет отличаться от сценария.

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

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