Дизайн приложения Zend Framework - доступ к переменным сеанса на уровне модели

Question

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

редактирование: Одна из причин, по которой мне не нравятся сеансы в моделях, заключается в том, что они, кажется, усложняют тестирование. Сохраните это как просто передаваемые в функции параметры, а затем набор записей передайте обратно.

ТНХ

Answer 1

Это зависит.

Я думаю об этом так:

1. Модель представляет ваш уровень данных.
2. большую часть времени этот уровень данныхбудет базироваться на таблице БД
3. . Сеанс - это просто еще один носитель данных.
4. Заключение : Если данные, которые представляет ваша модель, хранятся в сеансе, чем ониOK, чтобы получить доступ к этим данным из модели

Примером является корзина покупок на основе сеанса.Объекты моей корзины являются моделями данных моего сеанса.

Answer 2

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

Answer 3

Нет, не должно.Тип хранилища должен отличаться от вашей бизнес-логики.Например:

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

$User = Zend_Registry::get('User'); // User model object

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

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

Подход ООП и многоуровневого системного подхода состоит в том, чтобы создавать специализированные объекты и слои и упростить задачу, предотвращая распространение определенных действий по всему коду.

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

Answer 4

Что хранится в переменных сеанса? Если это просто «залогинен? Да / нет ', тогда они, вероятно, не должны быть частью уровня модели. Однако, если он более сложный, он, вероятно, неразрывно связан с вашей бизнес-моделью и должен рассматриваться как таковой.

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