MVC - Теоретический вопрос

Question

Это скорее теоретический вопрос, а не конкретный язык, но я в основном имею в виду AS3.

Допустим, у меня есть приложение, которое показывает кнопки на нескольких уровнях навигации.

Например artistsAlphabetical->albums->songs или songsAlphabetical->song или albumsAlphabetical->album->song

поэтому мы настроили модель (данные) со всеми песнями (наименьший общий знаменатель - в объекте песни была бы информация об исполнителе / ​​альбоме / годе и т. Д.)

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

Куда это должно попасть? Модель или контроллер?

Я могу найти причины и того, и другого, но мне интересно, каким был бы "корректирующий" способ.

Далее у нас есть вид со всеми кнопками для сортировки.

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

Какая часть MVC должна отвечать за каждый шаг?

Создание списка исполнителей, начинающихся с A

будет ли контроллер, который скажет: «Эй, модель - Художники, которые начинают с« A »СЕЙЧАС!»

или, может быть, это будет больше похоже на "Модель - пришлите мне список всех художников, мне нужно найти А-Догу"?

по сути, должна ли модель выполнять сортировку (и кэшировать ее, если это возможно / необходимо) или логика должна находиться под контроллером, и модель может хранить кэш?

Итак, когда у нас есть список исполнителей, нам нужно создать кнопку для всех тех, кто помещается на экране, плюс несколько кнопок «предыдущий / следующий». Кто должен создавать кнопки?

Должен ли быть контроллер вида? Суб-контроллер, который имеет дело только с логикой, необходимой для создания представлений? Или логика была бы частью View? Мне кажется, что контроллер приложения будет похож на «не в описании моей работы ... Я дал вам список, который вам нужен, остальное зависит от вас»

Мне кажется, что я нахожусь в противоречии между двумя представлениями MVC, одним ( mvC ) - когда контроллер работает как материнская метка, а модель является прославленным держателем данных, а представление управляет объектами DisplayObject. Или ( MVc ), где контроллером является менеджер / делегат, который обеспечивает правильную связь Модели и Представления, так что модель и представление будут иметь достаточное количество логики, и контроллер будет обрабатывать общение и делегирование взаимодействия на высшем уровне.

Хотя я делаю большую часть своей работы в AS3, мне любопытно, как другие языки справятся с этим. Например, в PHP Frameworks вам не нужно беспокоиться о логике кнопок и обработке событий так же, как с as3, где вам нужно наблюдать за сборкой мусора, поэтому рабочая нагрузка одного компонента там может отличаться от Cinder ++, приложение для обработки или ActionScript.

Answer 1

Я не знаю AS3.Я работаю как с Spring MVC / Java, который действительно позволяет использовать оба подхода, так и с Ruby on Rails, который предпочитает умные модели и тупые контроллеры.Мне больше нравится подход «умная модель / тупой контроллер».

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

В Rails я бы поставил процесс создания набора кнопок на уровне представления без вопросов.Если задействована реальная логика, то это войдет в вспомогательный метод view.

Answer 2

Как вы уже сказали, это сводится в основном к предпочтениям, но обычно я выбираю сортировку в контроллере.Я склонен хранить свои модели исключительно в отношении хранения данных и уменьшать количество функциональности в них.Таким образом, в вашем примере работа модели будет заключаться в том, чтобы хранить все данные об исполнителях, а работа контроллера - извлекать из этих данных исполнителей, начинающихся с буквы «А», и затем передавать отсортированные данные в представление.

Answer 3

Я больше не использую традиционный MVC, поэтому я склонен больше думать о PureMVC (прокси, посредниках и командах).

В общем, я склоняюсь к более функциональным прокси (думаю, модель)) где данные абстрагируются (по типичным причинам абстрагирования данных).Таким образом, в ваших случаях был бы прокси MusicLibrary и, вероятно, имел бы такие методы, как byArtist (), byTitle (), byRandom () и т. Д.

В приложении PureMVC последовательность для вашего сценариявыглядит так:

1. Компонент ловит щелчок мышью и отправляет Mouse.CLICK
2. Посредник, обрабатывающий компонент, ловит событие и отправляет уведомление SORTBY_ARTIST_CLICKED
3. Команда, запрашивающая уведомление оSORTBY_ARTIST_CLICKED, вызывает метод byArtist () на прокси-сервере, создает уведомление NEW_MUSIC_LIST с данными и отправляет их
4. Посредник, запрашивающий уведомление NEW_MUSIC_LIST, затем выполняет свое действие и обновляет компоненты, вызывает споры

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

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