CodeIgniter: принятие решения о создании библиотеки и помощника в CodeIgniter

После некоторой разработки в CodeIgniter мне стало трудно принимать решения о том, когда создавать пользовательскую библиотеку и когда создавать пользовательский помощник.

Я понимаю, что оба позволяют иметь бизнес-логику в ней и могут повторно использоваться в рамках (вызов с другого контроллера и т. Д.)

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

CI разработчики там, пожалуйста, посоветуйте.

Я думаю, что лучше включить пример.

Я мог бы иметь

class notification_lib {
   function set_message() { /*...*/}

   function get_message() {/*...*/}

   function update_message() {/*...*/}
}

Кроме того, я мог бы также включить все функции в помощник.

В notification_helper.php файл, я буду включать set_message(), get_message(), update_message()..

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

В обычном php-приложении (без фреймворка) выбор очевиден, поскольку нет помощника, вам просто нужно создать библиотеку для повторного использования кодов. Но здесь, в CI, я хотел бы понять ядро ​​разработчиков разделения библиотек и помощников

Источник

6 ответов

Решение

Принимая решение, я задаю себе вопрос, который, я думаю, также поможет вам. Вопрос заключается в следующем: предоставляю ли я функцию моей структуре или я консолидирую?

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

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

Надеюсь, эта дифференциация поможет вам, как и я.

Источник

Ну, выбор сводится к набору функций или класса. Выбор почти такой же, как у экземпляра класса против статического класса.

Если у вас есть просто группа функций, то вам нужно всего лишь создать группу функций. Если эти группы функций совместно используют много данных, то вам нужно создать класс, у которого есть экземпляр для хранения этих данных между вызовами метода (функции класса).

У вас есть много публичных или частных объектов для хранения, связанных с вашими уведомлениями?

Если вы используете класс, вы можете установить несколько сообщений через систему, тогда get_messages() может вернуть приватный массив сообщений. Это сделало бы его идеальным для библиотеки.

Источник

Прежде всего, вы должны быть уверены, что понимаете разницу между CI libaray и вспомогательным классом. Вспомогательный класс - это все, что помогает любой готовой вещи, например array, string, uri, так далее; они есть, и PHP уже предоставляет функции для них, но вы все равно создаете помощника, чтобы добавить им больше функциональности. С другой стороны, libaray может быть чем-то похожим на то, что вы создаете впервые, любое решение, которое не обязательно уже существует.

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

Надеюсь, это поможет.

Спасибо

Источник

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

Доступные помощники в CI

Библиотеки обычно содержат не специфичные для CI функции. Как библиотека изображений. Нечто переносимое между приложениями.

Доступные библиотеки в CI

Ссылка на источник

Источник

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

Я думаю, что эти различия:

  • Класс: в двух словах, класс - это план объекта. А объект инкапсулирует концептуально связанные Состояние и Ответственность чего-либо в вашем Приложении и обычно предлагает программный интерфейс для взаимодействия с ними. Это способствует повторному использованию кода и улучшает удобство сопровождения.
  • Функции: функция - это фрагмент кода, который принимает еще один ввод в виде параметра, выполняет некоторую обработку и возвращает значение. Вы уже видели много функций, таких как fopen(), fread() и т. Д. Они являются встроенными функциями, но PHP также позволяет вам создавать свои собственные функции.

Так что перейдите на класс т.е. библиотеки, если какой-либо один пункт соответствует

  1. глобальную переменную нужно использовать в двух или более функциях или даже в одной, я ненавижу использовать ключевое слово Global
  2. инициализация по умолчанию в соответствии с каждым вызовом или загрузкой
  3. некоторые задачи являются частными для сущности, не являются публично открытыми, думаю, что функции никогда не имеют общедоступных модификаторов.
  4. функция для работы зависимостей, т.е. задачи разделены, но это нужно двум или более задачам. Подумайте о проверке validate_email только для сценария отправки электронной почты для to, cc, bcc и т. Д. все это необходимо validate_email.
  5. И, наконец, не в последнюю очередь все связанные задачи, т.е. функции должны быть помещены в один объект или файл, это проще для справки и запоминания.

Для помощников: любая точка, которая не совпадает с библиотеками

Источник

Лично я использую библиотеки для больших вещей, скажем, созданную мной FTP-библиотеку, которая намного быстрее, чем поставляемая библиотека CodeIgniters. Это класс с множеством методов, которые обмениваются данными друг с другом.

Я использую помощников для небольших задач, которые не связаны с большим количеством других функций. Небольшие функции, такие как декорирование строк, могут быть примером. Или рекурсивное копирование каталога в другое место.

Источник
Другие вопросы по тегам