Поиск способа обработки / доступа к веб-сайтам PHP OOP

Я не новичок в PHP или программировании вообще. Но в последнее время я думал о программировании веб-сайтов в PHP и о том, насколько это было до OOP. Во всяком случае, я предпочитаю ООП, чем старый процедурный стиль. Я хочу реализовать веб-сайт, но мне кажется, что мне всегда нужно использовать глобальные или статические переменные. И я начинаю удивляться, как я могу это сделать без них?

Во всяком случае, я говорю о том, чтобы иметь класс для каждого «компонента» веб-сайта. Например, если это был веб-сайт для сокращения URL, это будут: ссылки, члены, база данных.

То, о чем я говорю, более сложно, по крайней мере, 8 классов. Во всяком случае, мой нынешний подход таков:

$database = new Database(...); $links = new Links($db); $users = new Users($db); 

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

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

У вас должны быть следующие компоненты:

  1. Бизнес-объекты, которые моделируют и выражают одну конкретную вещь в приложении:

     class Link { ... } class User { ... } 

    Они ничего не делают, они просто формализуют ваши структуры данных. Эти объекты имеют методы getter и setter для получения и установки отдельных атрибутов, которые также проверяются там:

     public function setUrl($url) { if (!/* validate the URL here*/) { throw new InvalidArgumentException("$url is not a valid URL"); } $this->url = $url; } 

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

  2. Ссылка на базу данных. Только голая необходимая вещь для подключения к базе данных, ничего более, не меньше. Необработанный объект PDO или mysqli будет отлично работать.

  3. Mapper данных-данных, который берет ссылку на базу данных и знает, как хранить бизнес-объекты в базе данных и как их извлекать:

     class LinkStorage { protected $db; public function __construct(PDO $db) { $this->db = $db; } } 

    У этого класса есть все различные способы извлечения из вашей базы данных:

     public function getById($id) { $stmt = $this->db->prepare('SELECT ... FROM ... WHERE id = :id'); $stmt->execute(compact('id')); if (!$data = $stmt->fetch()) { throw new RuntimeException("Record with id $id does not exist"); } return new Link($data['url']); } 

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

     /** * Returns all links by a particular user. * @param User $user * @return Link[] */ public function getAllFromUser(User $user) { ... } 

Использование просто:

 $db = new PDO(...); $linkStorage = new LinkStorage($db); $userStorage = new UserStorage($db); $user = $userStorage->getById($id); $links = $linkStorage->getAllFromUser($user); 

Этот тип кода затем будет инкапсулирован в класс сервиса, который содержит все возможные «действия», которые вы можете сделать в своем приложении. registerUser(array $data) , getLinksOfUser($id) , newLinkFromPostData(array $data) и т. д.

То, что я только что описал, в основном является образцовой частью приложения в стиле MVC. Остальные две части будут контроллерами, которые вызывают методы службы, и представления, которые выводят данные из методов обслуживания. Этот подход сохраняет ответственность отдельно и изолированно и позволяет сочетать логику и функциональность более высокого уровня, как строительные блоки. Бизнес-объекты являются самым низким строительным блоком, их структура должна быть твердой и четко определенной для остальных. Передатчики данных-объектов просто заботятся о том, чтобы поместить эти объекты в базу данных и вернуть их обратно. Затем услуги объединяют все это различными способами и делают все возможное.

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

 $factory = new Factory; $userStorage = $factory->newUserStorage(); 

Вся сложность инстанцирования инкапсулирована на этом заводе. Еще один шаг – контейнеры для инъекций зависимостей, которые вы можете настроить, например, в XML-файле, чтобы указать, какой класс зависит от того, а затем контейнер DI позаботится об этом для вас.

Я думал о веб-программировании на PHP и о том, насколько это было проще, чем OOP

Ну, придерживайтесь процедурных тогда. Если проще писать хорошо написанный веб-сайт процедурным или функциональным способом, то он противоположен ориентированному на ojbect. Прикрепите то, к чему вы привыкли. OO не лучше функционально. Это совсем другой подход.

public void main () в php

В lanuage Java каждая часть программного обеспечения, которую мы пишем, имеет единственную точку входа. Метод public void main() . Этот метод запускает все приложение и передает аргументы, предоставленные при запуске. Это также единственная точка выхода в приложении. приложение заканчивается этим методом (если только он не сработает).

В php нет единой точки входа. У нас есть куча файлов, которые запускают некоторые скрипты, которые делают еще кое-что, а затем где-то вдоль линии другой скрипт решает вернуть материал и умереть ();

Зависимость инъекции и как библиотеки IoC могут помочь

При использовании инъекции зависимостей, она становится реальной болью в $$ при создании объектов и передаче arround правильного экземпляра класса. Мы начинаем решать эту проблему с уродливыми решениями: Singleton, globals, statics, … Делаем наше программное обеспечение все более и более тесно связанным и сложнее поддерживать.

Здесь может помочь инверсия управления. есть некоторые действительно смачные статьи на веб-сайте.

Вы можете использовать автозагрузку в PHP для лучшего решения:

http://php.net/manual/en/language.oop5.autoload.php