И мы используем внутренние стандарты.
Они действительно полезны: — Стандартам вообще не обязательно следовать.
; — позволяют быстрее и комфортнее привыкнуть к вещам; — помогают меньше теряться в творческом процессе.
Исторически мы активно использовали CodeIgniter. Вашему вниманию предлагается стандарт разработки приложений на CodeIgniter.
Контроллеры
1. За один функциональный модуль должен отвечать один контроллер.2. Модули с кросс-функциональностью можно выделить в отдельные контроллеры или присоединить к существующим.
В обоих случаях архитектурное решение должно быть одинаковым для всего изделия.
3. Каждый метод контроллера должен учитывать и по возможности выделять отдельные функциональные области: - права доступа; — получение и обработка данных; — вывод данных.
В этом случае можно использовать метод _remap(), расширить класс контроллера и дублировать функциональные области в каждом методе.
Важно, чтобы виды деятельности были четко определены и разделены.
4. Не следует использовать маршрутизацию, если ее можно избежать.
5. Не следует выводить данные из контроллера без прохождения класса Output (display), если это не AMF. 6. Имеет смысл использовать приватные функции для сокращения кода с идентичным функционалом.
7. Код публичных методов контроллеров должен быть высокоуровневым, кратким и лаконичным.
Все, казалось бы, рутинные действия имеет смысл выполнять в приватных методах контроллеров, моделей, представлений, помощников или библиотек.
8. Имеет смысл использовать понятные и краткие имена методов, которые дадут красивые и понятные URL-адреса, что, помимо прочего, способствует более комфортному обслуживанию программы.
Модели
1. Каждая модель выполняет действия только со связанной с ней сущностью.2. По возможности каждой сущности должна соответствовать одна таблица в базе данных.
Если, например, для обслуживания соединений требуются дополнительные таблицы, имеет смысл рассмотреть вопрос о том, делать ли соединение дополнительной сущностью со своей моделью.
3. Имеет смысл расширить класс моделей (пример ниже).
4. Имеет смысл использовать ORM. 5. Имеет смысл избегать сложных запросов в пользу серии простых запросов, которые позволяют кэшировать данные и выполнять более гибкую и быструю обработку.
6. Следует использовать Active Record. 7. Не следует хранить в базе данных информацию, которая не изменяется в процессе выполнения программы.
Дисплеи
1. Имеет смысл создать и использовать псевдоним для $this-> load-> view($view,$data, истинный ) в процедурном контексте (пример ниже).2. Представления могут загружать другие представления.
Вам следует использовать этот вариант: — организовать иерархическую структуру вывода - отделить функциональную логику вывода и процедуры от шаблонов - для разделения шаблонов дизайна.
Например, это дает возможность быстро и буквально переключать дизайны.
— для форматирования структурного и функционального вывода (HTML-страница, JSON, HTML-фрагмент, динамические данные) 3. Не следует создавать файлы или нединамические данные в представлениях.
4. На дисплеях можно изменить формат представления данных.
А вот содержимое данных в представлениях менять не стоит — для этого есть ООП-мощь контроллеров, моделей и библиотек, а также процедурных помощников.
5. Не следует использовать JavaScript в дисплеях, если нет очевидной необходимости поступать иначе.
Конфигурация
1. Имеет смысл создавать свои файлы конфигурации, так как родные имеют свойство обновляться вместе с фреймворком.2. Для функциональных конфигураций имеет смысл использовать подкаталоги.
3. Целесообразно включить в конфигурацию все конкретные данные и данные, которые могут измениться в ходе разработки проекта, вместо того, чтобы явно указывать их в программном коде.
Это позволяет вам быстрее находить их и комфортно изменять.
4. Для некоторых конфигурационных данных, которые могут измениться в процессе разработки проекта, имеет смысл предусмотреть денормализацию в базе данных для обеспечения корректности истории.
Библиотеки
1. Не следует создавать библиотеку, если необходимость ее создания не очевидна.Например, вместо библиотеки можно создать контроллер.
2. Библиотеки используют контекст объекта, и это необходимо учитывать перед проектированием библиотеки.
Основные пометки 1. Очень полезно изучать, следовать и перечитывать Руководство по стилю хотя бы раз в год. 2. Имеет смысл использовать решения, доступные в рамках, прежде чем создавать свои собственные альтернативы.
3. Каркас надежно и сверхлегкий.
Это подтверждено многими тестами и исследованиями.
Нет смысла оптимизировать.
4. Имеет смысл использовать встроенные в фреймворк средства отладки (режимы профилирования и регистрации ошибок).
5. Имеет смысл разместить каталоги приложений и системы, а также другие файлы, которые по умолчанию не должны быть доступны пользователям сайта, выше Document Root виртуального хоста.
6. Прежде чем проектировать что-то принципиально новое, имеет смысл посмотреть на Google, GitHub и BitBucket реализацию подобных задач.
С вероятностью 99% любая произвольная задача уже решена.
Все тривиальные проблемы имеют несколько возможных решений для CodeIgniter. 7. В автозагрузке имеет смысл указать, что достоверно часто используется в текущем и последующих приложениях.
8. Не следует при запуске указывать конкретные ресурсы, которые можно загрузить в конструкторах контроллера.
9. Комментарии хороши, когда они релевантны, кратки и написаны на английском языке.
10. TODO должно быть отмечено ключевым словом TODO. 11. Прежде чем использовать сторонние библиотеки, убедитесь, что они написаны на PHP5 (а не PHP4).
Вариант расширения application/core/MY_Model.php
Теги: #codeigniter #веб-разработка #php5 #разработка веб-сайтов #codeigniter<Эphp class MY_Model extends CI_Model {
-
Служба Поддержки Windows
19 Oct, 24 -
Алкина
19 Oct, 24 -
Сравнение Услуг Кабельного Или Dsl
19 Oct, 24 -
Любовь И Криптография
19 Oct, 24 -
Обнаружен Greebok. Сам Дерматовенеролог
19 Oct, 24
