Дизайн/наследование MVC

Question

Простите неопределенное название, я не был уверен, как его описать.

Если у вас есть общая модель «Архив», как вы показываете разные виды/формы на основе выбранного пользователем типа?

Например, пользователь создает новый «Архив», затем выбирает видео, книгу, аудио и т. Д. Оттуда они получают разные формы на основе типа архива.

Или было бы лучше разделить их на разные модели - видео, книги, аудио?

Могут ли модели наследовать (например, Video extends Archive). Я предполагаю, что это базовые ООП/классы, но понятия не имею, как применить это здесь.

Примеры из любой конструкции MVC приветствуются!

Answer 1

Похоже, вы не хотели бы наследовать тип от Архива. «Всегда предпочитайте инкапсуляцию/сдерживание над наследованием».

Почему бы не создать класс под названием Archive и присвоить ему свойство type. Тип может использовать наследование для специализации для аудио, видео и т. Д.

Казалось бы, вы специализируетесь на Архиве, основанном на некоторых других критериях. «FileSystemArchivce», «XMLArchive», «SQLArchive» и тип не изменились. Но аглилист во мне говорит, что это может быть не обязательно сначала, и вы можете всегда реорганизовать дизайн позже ...

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

Answer 2

Ваши модели Видео, книги и аудио могут наследоваться из архива.

И каждая модель будет иметь контроллер.

http://yourserver/Books/Edit/11

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

EDIT (в ответ на комментарий)

В ASP.NET MVC ваша модель будет класс.

public class Video : Archive 
{ 
    public int Id {get;set} 
    public string Name {get;set;}  
    ... 
} 

Вы также будете иметь контроллер

public class VideoController : Controller 
{ 
    public object Edit(int id) 
    { 
     Video myVideo = GetVideo(id); 
     return View("Edit", myVideo); 
    } 
    ... 
} 

И вы будете иметь представление в каталоге Views, например, страницу, содержащую

public class Edit : View<Video> 
{ 
    ... 
} 

Таким образом, вы можете назвать это, если у вас был URL-адрес, который был

http://localhost/Video/Edit/11

Все это было сделано из памяти, поэтому могут быть некоторые ошибки, но сообщение о возврате - это указание наследования в модели. Модель - это всего лишь класс. В вашем случае вы хотите наследовать из Архива. Как только вы это сделаете, модель проходит нормально.

Answer 3

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

Для примера рассмотрим проект Apache Struts. Как указано в Struts для новичков: «Чтобы хорошо использовать Struts, важно иметь хорошее представление об основных принципах. Начните с рассмотрения Key Technologies primer и изучения любых незнакомых тем."

Для другого ресурса, см Web-Tier Application Framework Design (Sun J2EE Blueprints)

Answer 4

На самом деле показать другой вид должен быть легким в любых рамках MVC. Например, в Microsoft ASP.NET MVC вы бы не просто вернуть вид от контроллера, как следующее:

return View(); 

, но фактически указать имя представления в качестве параметра:

return View("VideoArchive"); 

, который будет затем отобразите представление из Views/Archive/VideoArchive.aspx

Answer 5

Single Responsibility Principle (PDF) говорится, что:

никогда не должно быть больше, чем одна из причин КЛАССА ИЗМЕНИТЬ.

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

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

Как только у вас есть эта иерархия классов, вам нужен только один контроллер и просмотр для каждого класса модели.

Для бонусных очков принцип единой ответственности может даже оправдывать использование фабричного метода или абстрактной фабрики для создания объектов модели, вида и контроллера (а не для их встраивания). В конце концов, создание объекта и использование этого объекта - разные обязанности, которые, возможно, необходимо изменить по разным причинам.