Правильный способ построить MVC для моего приложения

Question

Я собираю данные, которые я хочу очистить тремя поисковыми системами.В Моих запросах_контроллере у меня будет функция поиска, которая вызывает $this->Query->find('$query').Моя модель передаст это в мою собственную базу данных, чья функция read() вызовет три функции: searchGoogle($query), searchYahoo($query) и searchBing($query).Возвращаемые значения будут стандартизированы некоторыми вспомогательными функциями, определенными в базе данных, а затем добавлены в массив, который возвращает read().Моя модель просто передаст эту информацию на контроллер, который отобразит ее в виде.В то же время контроллер запишет в базу данных MySQL все результаты моего запроса с помощью дополнительной модели, чью функцию write () он вызовет.

Правильно ли, что все функции будут в базе данных или еслибазы данных вернуть грубое содержание и оставить его модели для его стандартизации?У моей модели есть другая модель, записывающая ее в базу данных, или это будет контроллер?я хотел бы иметь помощников в базе данных для стандартизации и есть ли что-то вроде extends для функций, чтобы у них у всех был один и тот же массив возврата?Могу ли я определить, какой массив должен иметь мой поиск?

Answer 1

Звучит так, будто здесь происходит очень много абстракций, но я не могу сказать, является ли это реальной абстракцией, если вы просто используете несколько терминов (например, «помощник») неоднозначно. Вообще говоря, ваша модель будет общаться с вашим источником данных. Этим источником данных может быть база данных, служба, простой файл или некоторая комбинация любого / всех из них. Я регулярно пользуюсь внешним сервисом для сбора большей части данных модели, а затем немного уточняю их с помощью данных, ориентированных на приложения, взятых из специализированной базы данных.

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

Короткая версия: не усложняйте (и в рамках соглашения). Позвольте вашему контроллеру обрабатывать поток приложений и деятельность, ориентированную на приложения (например, обмен сообщениями, доступ к сеансу и т. Д.), Пусть ваша модель обрабатывает доступ / поиск / манипулирование данными, и пусть ваше представление беспокоится о том, как отобразить данные, возвращенные из модели (через контроллер).

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

Answer 2

Как правило, вы хотите избежать логики в вашей базе данных. База данных должна отвечать за возврат данных, а затем Модель будет отвечать за то, что ей нужно. Масштабирование базы данных гораздо сложнее, чем увеличение вычислительной мощности. Код в базе данных гораздо сложнее поддерживать в дополнение к проблемам масштабируемости.

Answer 3

Имейте в виду, лучшая практика для CakePHP (и большинства архитектур MVC в целом):

Model = fat
Controller = thin
View = skinny

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

Хелперы предназначены для облегчения функциональности представления, в то время как элементы являются представлениями многократного использования.

Что касается остальных ваших вопросов, может быть проще разбить их на отдельные вопросы с примерами кода, если вы застряли где-то.