При кодировании PHP я решил перейти от кода спагетти и попытаться реализовать MVC. Чтобы реализовать структуру MVC, я выхожу в эту статью. Статья дала хорошее начало, и мне удалось создать свой сайт и разработать интерфейс. Теперь я пытаюсь реализовать back-end, используя сеансы и другие функции для членов. Мой мозг кипит с новой информацией, и у меня больше вопросов, чем ответов.
Я не знаю, как реализовать дополнительные классы, например, user класс. Например, без MVC я мог бы создать новый файл класса user.php в моем каталоге include, затем включить его, создать экземпляр и назначить соответствующие значения объекту и поместить объект в сеанс.
Я хотел бы попросить посоветовать.
Я запутался во многих вещах:
Вероятно, это общая проблема, которая не является сложной, как только это было сделано раньше. Я также извиняюсь за not very good defined question , но я ценю вашу помощь заранее.
User , контекст MVC, является объектом домена . Однако сеанс – это форма носителя данных (как кеш, db или файловая система). Когда вам нужно хранить данные из экземпляра User там, вы можете использовать некоторый тип dataperper для этого.
$user = $this->domainObjectFactory->build('user'); $user->setName('Korben') ->setSurname('Dallas'); if ( some_condition ) { $mapper = $this->dataMapperFactory->create('session'); $mapper->store($user); }
Этот код должен обеспечить чрезвычайно упрощенный пример взаимодействия между сеансом и пользователем.
В качестве объекта домена экземпляры User должны использоваться внутри служб и инициализироваться с использованием заводов. В контексте MVC сервисы представляют собой структуры на уровне модели, которые имеют дело с логикой приложения . Они манипулируют и облегчают взаимодействие объектов домена и абстракций хранения.
Все ваши классы должны быть добавлены с помощью автозагрузчика. Вы должны прочитать об использовании spl_autoload_register() , желательно при использовании пространств имен .
Инициализация самого экземпляра должна выполняться на заводе. Это позволяет отделить ваш код от имени класса указанного экземпляра.
Вы этого не сделаете.
Приложения PHP не сохраняются. У вас есть HTTP-запрос, вы делаете все, что вам нужно, ответ отправляется и приложение уничтожается. Экземпляры класса User будут недолговечными.
Чтобы восстановить текущего пользователя между запросами, вы храните идентификатор в сеансе. Не сбрасывайте все объекты в сеансе . Вместо этого после получения идентификатора пользователя из сеанса вы можете восстановить остальные данные учетной записи пользователя из других форм хранилища (если вам это даже нужно).
Весь этот процесс должен быть предварительно сформирован и управляться каким-то «службой распознавания» или «службой аутентификации» на вашем уровне модели.
Запрос на вход сначала обрабатывается контроллером:
public function postLogin( $request ) { $service = $this->serviceFactory->create('recognition'); $service->authenticate( $request->getParameter('username'), $request->getParameter('password') ); }
Служба пытается проверить учетные данные пользователя, что изменяет состояние уровня модели. Экземпляр просмотра затем просматривает это состояние и перенаправляет вас на целевую страницу как аутентифицированный пользователь или перенаправляет вас на страницу входа с сообщением об ошибке.
Сами сервисы будут совместно использоваться контроллером модели и просматривать через завод. Это означает, что они будут инициализировать каждую службу только один раз, а затем просто повторно использовать ее. Что-то вроде:
class ServiceFactory { private $cache = array(); public function create( $name ) { if ( array_key_exists($name, $this->cache) === false ) { $this->cache[$name] = new $name; } return $this->cache[$name]; } }
Просто имейте в виду, что он является чрезвычайно упрощенным примером.
Для дальнейшего чтения я бы порекомендовал вам пройти через эту подборку ссылок . Кроме того, вы можете найти эти 3 сообщения несколько полезными: это , это и это .
Поэтому у вас здесь много вопросов, давайте кратко рассмотрим их:
Как вы можете себе представить, мы не можем технически ответить на эти вопросы в Stackoverflow. Было бы мало пользы для будущих пользователей вашего вопроса, и мы просто не хотим давать простые ответы.
Но если вы просмотрите список своих вопросов, вы можете узнать некоторые важные моменты:
А также уже ответ: «В модели» (не для этих двух пунктов, которые я только что перечислил, но для некоторых из ваших вопросов).
Поэтому, прежде всего, модель представляет собой слой в MVC. И слой – это определенная область вашего приложения, которая заботится о работе (обычно более высокоуровневой) в своем потоке. В вашем примере Пользователь является частью Модели . См. « Макаронную теорию программного обеспечения» для описания того, как вы можете организовать код в программном обеспечении, это должно четко указать, почему использовать слои – помимо специфического MVC. Но в MVC ответ ясен: в модели.
Поскольку этот ответ настолько очевиден, это заставляет меня немного удивляться тому, как урок, за которым вы следовали, мог пропустить это. И вы остались наедине с такими элементарными вопросами разработки программного обеспечения, как:
Поскольку эти два вопроса довольно экзистенциальны для любого программного обеспечения, которое использует объекты , даже те, которые специально объектно-ориентированы.
Поэтому давайте просто держим это прямо и ответим на эти два вопроса: для MVC вы можете создать себе некоторые подпрограммы высокого уровня, которые образуют структуру, в которой вы создаете ваше приложение. В основном это означает, что вы создаете библиотеку. Кто-то использует библиотеку. То, что кто-то должен решить, где создаются объекты. Структура / библиотека не должна определять, где создавать объекты и не создавать объекты для пользователя. Поэтому на эти вопросы должен отвечать потребитель вашей структуры не автор рамок. Поэтому, чтобы правильно справиться с этим, вам нужно разделить себя на две части и, с одной стороны, взять на себя роль кодера библиотеки, а с другой стороны взять на себя роль кодера, записывающего приложение в библиотеку.
Я могу только подчеркнуть этот очень простой, но принципиальный момент: когда вы пишете библиотечное программное обеспечение / фреймворк, не продиктовывайте, где создавать объекты. Просто дайте тесты, которые доказывают, что ваша библиотека работает без какого-либо приложения, а затем, когда вы пишете приложение, просто включайте библиотеку и используйте ее.
Второй вопрос, который вы задаете, – это как объекты передаются через мое приложение? , Внимательно изучив урок, который вы связали, вы уже можете видеть, что мои общие рекомендации, приведенные выше, не соблюдаются (что имеет решающее значение для быстрого развития кстати, поэтому не заблуждайтесь в заголовке учебника: с таким сложным кодом он предложения, только первый час прошел быстро, и он проложил дорогу только для сложной разработки ), но также, что примерный код учебника не является полезным примером для ответа на вопрос о том, как передавать объекты в приложении. Это не позволяет объяснить очень простой, но эффективный метод для этого: Injection Dependency .
Поэтому не просто взять один учебник как должное. Тот, который вы выбрали, просто показывает следующее:
И поскольку последний момент – это полное отсутствие, я настоятельно рекомендую вам отбросить все, что вы сделали до сих пор из этих примеров, и попробовать следующий. Просто имейте в виду, что пользователю библиотеки необходимо решить, где и когда создавать объекты (это означает, что используемая библиотека (ы) должна позволять это всегда) и что вы используете инъекцию зависимостей для передачи объектов через граф объектов, который вы используете в своем заявление.
Почему бы не использовать одну из многих существующих инфраструктур MVC для PHP? Там много (CakePHP, CodeIgniter, Yii и т. Д. И т. Д.).
Если вы действительно хотите заново изобрести колесо, продолжайте! Однако существующие рамки представляют собой кульминацию большого развития умных людей, поэтому вы получаете отличное начало, приняв его.
Кроме того, они хорошо документированы и имеют хорошие учебные пособия, которые будут отвечать на задаваемые вами вопросы, а также многие, о которых вы еще не спросили.