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

Question

Простите за смутное название, я не знал, как это описать.

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

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

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

Или модели могут наследовать (например, Видео расширяет Архив). Я предполагаю, что это основные ООП / классы, но я не знаю, как применить это здесь.

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

Answer 1

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

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

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

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

Answer 2

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

return View();

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

return View("VideoArchive");

, который затем будет отображать вид из Views / Archive / VideoArchive.aspx

Answer 3

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

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

http://yourserver/Books/Edit/11

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

РЕДАКТИРОВАТЬ (в ответ на комментарий)

В 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 4

Принцип единой ответственности (PDF) гласит:

НЕ ДОЛЖНО БЫТЬ БОЛЬШЕ, ЧЕМ ОДНА ПРИЧИНА КЛАССА ДЛЯ ИЗМЕНЕНИЯ.

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

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

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

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

Answer 5

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

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

Информацию о другом ресурсе см. В Разработка инфраструктуры приложений веб-уровня (чертежи Sun J2EE)