В веб-приложении MVC кто отвечает за фильтрацию больших коллекций объектов, представлений или моделей?

Question

У меня есть веб-приложение, построенное на дизайне MVC.

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

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

Так, как мне решить это? Должен ли я создать дополнительную модель, скажем, FilteredThreadsList, и запомнить ли она используемый фильтр, а затем использовать FilteredView для отображения списка потоков, которые выплевывает FilteredThreadsList?

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

Answer 1

Вы никогда не должны запрашивать данные из представления. Я не знаю, какой фреймворк вы используете в частности, но что касается Ruby on Rails (должно быть то же самое для других фреймворков), мы всегда извлекаем необходимые данные из контроллера и сохраняем всю эту информацию в переменной. Доступ к переменной будет осуществляться из представления, что поможет вам избежать запросов к базе данных напрямую из представления. Если код для запроса к базе данных становится слишком длинным в контроллере, вставьте этот код в модель, чтобы он был более понятным для вашего проекта в будущее. Кроме того, вы можете вызвать этот метод модели из нескольких мест в вашем приложении, если это необходимо. Удачи!

Answer 2

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

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

Суть заключается в следующем: если ваша логика фильтрации является общей, вставьте ее в контроллер, а затем вставьте в модель.

Answer 3

Модель , это всего лишь группа сущностей.

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

Что касается того, какие сущности и какое представление использовать для их представления, я думаю, что это работа Controller . Если вам нужна некоторая поддержка на «уровне модели», добавьте ее, но избегайте жесткой связи.