CodeIgniter вопрос

Question

Я думаю об использовании CodeIgniter для нового проекта. Я читал руководство пользователя для CI и заметил несколько вещей. Во всех своих примерах они, кажется, помещают всю логику в контроллер и просто используют модель для получения и установки данных. Мне нравится помещать всю мою логику в мою модель.

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

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

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

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

Спасибо

РЕДАКТИРОВАТЬ: Мне нравится использовать Fat Models и тощие контроллеры, так что я могу использовать одни и те же функции в более чем одном месте.

Просто прочитайте о Кохане, я думаю, что я подробнее расскажу об этом

Answer 1

Вы сделали много предположений из некоторых базовых примеров, которые не совсем верны.

Контроллеры должны содержать взаимодействие логика.

Это означает, что ваши контроллеры должны просто сказать, какие модели, представления, библиотеки и т. Д. Следует использовать в зависимости от того, что делает пользователь.

Модели содержат данные логика.

Это может быть ваша бизнес-логика, расчеты налогов, всякая работа с данными. Примеры в руководстве пользователя предлагают просто использовать Models в качестве «оболочки для базы данных», но вы можете делать с ними все что угодно. Простая модель представляет ваши данные, а остальная часть вашего приложения не должна заботиться о том, откуда они пришли.

Мои модели содержат смесь анализа файлов XML, вызовов методов REST и, конечно, некоторых запросов ActiveRecord.

Просмотры просто показывают вещи, поэтому не имеют представления о состоянии входа / выхода. Вы, конечно, должны сообщить об этом своему контроллеру (или глобальному коду, например MY_Controller , который ИМХО нужен практически каждому приложению приличного размера).

Сессии, хранящиеся в виде зашифрованных файлов cookie, совершенно безопасны. Они смогут декодировать их только в том случае, если они знают ключ шифрования вашего приложения, но это очень маловероятно, если вы не установите его; в этом случае вы сами виноваты.

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

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

Answer 2

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

CodeIgniter ожидает очень мало логики в своих моделях и вместо этого дает вам очень глупую оболочку SQL для возврата простых массивов типов POD для представления ваших данных. Он даже помещает много проверочного кода в контроллеры, что (на мой взгляд) неверно и повторяется. Я разработал собственное решение для проверки моделей в стиле Rails и метода динамического поиска, позволяющего использовать такие вещи, как

// inside model: 
// username must be 8 to 25 chars long
$this->validates_length_of('username', 8, 25);

// dynamically handled via __call()
$this->User->find_first_by_username('john'); // Return object or null
$this->User->find(); // select *
$this->User->find_by_group('admin'); // return 0 or more records

но AFAIK нет никакого встроенного способа сделать подобные вещи с CodeIgniter.

Кроме того, все переменные доступны для всех трех частей

Нет; Вы должны вручную передать переменные из контроллера в представление, и переменные не будут передаваться моделям / контроллерам или моделям / представлениям.

Я считаю, что метод, предложенный CodeIgniter:

<?php

function users() {
  $data['users'] = $this->User->find(); 

  // must use $data['users'] for controller logic; verbose and annoying

  $this->load->view('users/index', $data); // $users defined for view
}

?>

можно улучшить, используя ключевое слово PHP compact:

<?php

function users() {
  $users  = $this->User->find(); 

  // now we can use $users more easily

  $this->load->view('users/index', compact('users'));
}

?>

Я заметил, что данные сеанса хранятся в файлах cookie

CodeIgniter может хранить данные сеанса в базе данных; смотрите $config['sess_use_database'] в config / config.php. Там есть и другие параметры конфигурации, которые относятся к времени жизни файла cookie сеанса.

Я склонен сказать, что единственное, что CodeIgniter делает хорошо, это их документация, узнайте больше о конфигурации сеанса и их реализации активной записи (на самом деле не зависящий от языка SQL обертка, которая не имеет ничего общего с шаблоном Active Record)

Answer 3

CodeIgniter основан на шаблоне разработки Model-View-Controller. Модель представляет ваши структуры данных и должна использоваться только для этого.

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

Answer 4

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

Answer 5

AFAIK, идентификатор сеанса зашифрован и сохраняется в файлах cookie, но данные сеанса хранятся в локальной базе данных.

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