Проектирование/наследование модели MVC

StackOverflow https://stackoverflow.com/questions/129283

Вопрос

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

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

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

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

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

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

Это было полезно?

Решение

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

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

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

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

Другие советы

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

return View();

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

return View("VideoArchive");

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

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

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

http://вашсервер/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/Видео/Редактировать/11

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

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

Взгляните на Апач Стратс проект для примеров.Как сказано в Стойки для новичков, «Чтобы эффективно использовать Struts, важно хорошо понимать основы.Начните с рассмотрения Основные технологии, и изучение любых незнакомых тем».

Другой ресурс см. Проектирование платформы веб-приложений (Схемы Sun J2EE)

А Принцип единой ответственности (PDF) утверждает, что:

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

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

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

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

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

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top