Как организовать бизнес-логику в проекте Kohana 3

Я бы использовал модуль аутентификации, который поставляется с 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.

Вот еще несколько проектов, которые могут вас заинтересовать:

• Shindig - облегченный модуль блога для kohana 3
• Kohanut - расширяемая CMS, написанная на Kohana 3

Существуют ли соглашения или передовые практики о том, как структурировать расширяемую область входа для конечных пользователей в проекте 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/

Как видите, подчеркивания в имени контроллера действуют как разделители каталогов. Это справедливо для моделей и ванильных классов.