Общее правило - когда использовать модель (Codeigniter)

Question

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

Однако в настоящее время я создаю приложение, в котором есть таблица «config», которая содержит различные данные, например последнее обновление, которое будет контролировать, когда должны отображаться определенные функции в приложении. В этом случае мне в основном нужно будет извлечь данные из таблицы конфигурации. Стоит ли ставить эти методы конфигурации в модель?

Мне интересно услышать, как более опытные кодировщики подходят к методологии MVC в CI - например, псевдо-методы (например, какие методы, относящиеся к тому же объекту, который вы использовали бы в модели и контроллере) были бы наиболее полезными.

Answer 1

"Стоит ли использовать эти методы конфигурации в модели?"

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

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

Это означает, что выгода от абстрагирования вашей модели от контроллера заключается в том, что ваши контроллеры могут не знать, как хранятся ваши данные. Вы можете решить переключить ваши данные из базы данных в XML-файлы в INI-файлы, если методы моделей последовательно предлагают результаты в формате, который ожидает контроллер. Короче говоря, когда вы переключаете свой источник данных, вам нужно будет только обновить внутренние методы вашей модели, а не ваши контроллеры.

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

Answer 2

Вы отделяете M от V & C по многим тем же причинам, по которым вы отделяете свой CSS от своего HTML - абстракция, простота повторного использования и более легкий, более читаемый код.

Также обратите внимание, что с другими платформами MVC у вас не будет выбора. То, что вы можете игнорировать методологию (в КИ), не означает, что вы должны сделать это.