Как расположить бизнес-логику в проекте Kohana 3
Я ищу совет, учебные руководства и ссылки в том, как настроить веб-приложение среднего размера с Kohana 3. Я реализовал шаблоны MVC в прошлом, но никогда не работал против "формализованной" платформы MVC, таким образом, я все еще получаю голову вокруг терминологии - играющий вокруг с основными примерами, создавая представления и шаблоны, и так далее.
Я прогрессирую довольно хорошо, но я хочу настроить реальный веб-проект (одно мое собственное, которое я планировал в течение достаточно долгого времени теперь) как объект изучения.
Я учусь лучше всего примером, но основанная на примере документация немного редка для Kohana 3 прямо сейчас - они говорят так сами относительно сайта. В то время как я не волнуюсь по поводу изучения платформы, поскольку я продвигаюсь, я хочу удостовериться, что кодовая база целебно структурирована от запуска - т.е. контроллеры разделяют приятно, называют хорошо и согласно стандартам, и самое главное бизнес-логика разделена на соответственно размерные модели.
Мое приложение, в его ядре, могло быть описано как бизнес-каталог с диапазоном поиска и перечисляющих функций и области входа в систему для каждого владельца записи. Фактический административный бэкенд базы данных уже заботится о.
Предположим, у меня есть весь разработанный API, и на месте уже - перечисляют все компании, редактируют бизнес, перечисляют компании названием улицы, создают предложение, зарегистрированное как бизнес, и так далее, и я просто ищу, как вместить функциональность в шаблон MVC и в структуру приложения Kohana, которая может быть легко расширена.
Вы знаете реальные примеры "тяжелых базой данных" приложений как каталоги, онлайн-сообщества... с областью входа в систему основывались на Kohana 3, предпочтительно Открытый исходный код, таким образом, я мог посмотреть, как они делают это?
Есть ли конвенции или лучшие практики о том, как структурировать растяжимую область входа в систему для конечных пользователей в проекте Kohana, который не только может обработать страницу бизнес-каталога, но дальнейшие продукты на отдельных страницах также?
Вы знаете какие-либо хорошие ресурсы при создавании сложных приложений с Kohana?
Вы создали что-то подобное и могли дать мне рекомендации на структуре проекта?
Щедрость
Я присуждаю щедрость @antpaw, потому что он предоставил мне приложение Kohana с некоторой бизнес-логикой, которая дает мне много примеров. Аплодисменты @Pixel Разработчик для Вашего превосходного входа также - как так часто, мне жаль бы, что нельзя было разделить щедрость!
2 ответа
Я бы использовал модуль auth, который поставляется с kohana для входа в систему. Это даст вам таблицу ролей, где вы сможете настроить возможные варианты разрешений и связать их с пользователями позже. После этого вы можете проверить внутри __constructor() или action_function() каждого контроллера, имеет ли пользователь требуемую роль, например, с помощью функции ->has(). Вы также должны использовать модуль ORM, он просто потрясающий, так как у вас много связей между таблицами. Также метод __get() внутри объекта ORM может быть очень удобным.
Также довольно легко расширить функцию контроллера, установив новый параметр в NULL и проверив это в операторе if. Например, вам нужна только одна функция для редактирования старой или добавления новой записи.
public funciton action_manage($id = NULL)
{
$entry = ORM::factory('entry', $id); // if id is null a new entry will be returned
}
Также важно структурировать представления по вложенным папкам, чтобы избежать беспорядочного каталога представлений.
Здесь много вопросов, я постараюсь.
Знаете ли вы примеры из реальной жизни приложений, "загруженных базами данных", таких как каталоги, онлайн-сообщества ... с областью входа, построенной на Kohana 3, где я мог бы посмотреть, как они это делают?
Есть несколько примеров приложений. Вуди Гилк (основатель Kohana) опубликовал код на своем личном сайте на github . Для области входа он присваивает значение cookie. Kohana 3 / 2.4 подписывает файлы cookie, что делает его безопасным и устраняет необходимость в сеансах. Это может быть не на любой вкус, поэтому вы всегда можете использовать встроенную библиотеку аутентификации, которая использует как сеансы, так и файлы cookie.
Вот еще несколько проектов, которые могут вас заинтересовать:
Существуют ли соглашения или лучшие практики о том, как структурировать расширяемую область входа для конечных пользователей в проекте Kohana, который может обрабатывать не только страницу бизнес-каталога, но и другие продукты на отдельных страницах?
Если я правильно вас понял, вы хотите создать окно входа в систему для каждой из этих страниц? Это легко сделать с Kohana 3, поскольку мы можем воспользоваться преимуществом H в HMVC. Сэм де Фрессиине написал статью, подробно описывающую все это, в блоге iBuilding Tech Blog. Масштабирование веб-приложений с помощью HMVC .
Затем вы можете выполнить внутренний запрос к контроллеру или действию входа в систему и выгрузить ответ на страницу просмотра.
$login = Request::factory('login')->execute()->response;
$ login теперь содержит форму входа в систему, которую вы можете разместить где угодно. Вы можете захотеть вернуть другой ответ, если запрос является внутренним, поэтому этот фрагмент кода может быть полезен:
if (Request::instance() !== $this->request)
{
print 'Internal called made with Request::factory';
}
Знаете ли вы какие-либо хорошие ресурсы по созданию сложных приложений с помощью Kohana?
Документации, показывающей, не будет. вы, как создавать сложные приложения. Сообщество Kohana считает, что вы разработчик PHP и должны уметь решать эти проблемы самостоятельно. Если вы не можете, тогда вам не следует использовать Kohana.
Вы создали что-то подобное и могли бы дать мне рекомендации по структуре проекта?
Как только вы поймете, как Kohana 3 находит файлы, все станет легко для понимания.
|- classes
|-- controller
|-- model
|- views
Например:
Controller_Mathew extends Controller
Будет искать файл с именем mathew.php в:
classes/controller
Подчеркивание может использоваться для указания более глубоких каталогов. Пример:
Controller_Mathew_Davies extends Controller
будет искать файл с именем davies.php в:
classes/controller/mathew/
Как видите, подчеркивания в имени контроллера действуют как разделители каталогов. Это справедливо для моделей и ванильных классов.