Попытка писать в ООП. Вопрос во взаимодействии классов с БД

Статус
В этой теме нельзя размещать новые ответы.

Страшный Злодей

Бывший член клуба (достало хамство).
Всегда писал в процедурном стиле и все устраивало. Но вот сейчас почему-то захотелось в попробовать написать что-то в стиле ООП. Захотелось, ну и сразу как-то обломалось... Короче говоря, столкнулся с тем, что не могу придумать как правильно спроектировать взаимодействие классов с подключением к БД. Собственно моя проблема в том, что хочется прописывать все учетные данные БД (логин, пароль, хост, имя базы) и настройки подключения в одном файле и в дальнейшем использовать это подключение во всех создаваемых классах, каждый из которых планирую размещать в отдельных файлах. Прошу прощения, если вопрос сформулировал слишком расплывчато, попробую обобщить сказанное примером:

Есть файл подключения к БД dbconn.php (в комментах некоторые вопросы):

PHP:
class DBConnection {

private $db_host = 'localhost';
private $db_name = 'name';
private $db_username = 'user';
private $db_password = 'password';
public $mysqli;

/*
или лучше так?
private $mysqli;
public $result;
тогда придется создавать методы для каждого взаимодействия с базой: SELECT, UPDATE, INSERT и т.д... нужно ли это?
*/
public function __construct() {
    $this->mysqli = new mysqli( $this->db_host, $this->db_username, $this->db_password, $this->db_name );
    if (mysqli_connect_errno()) {
        printf("Подключение к серверу MySQL невозможно. Код ошибки: %s\n", mysqli_connect_error());
        exit;
    }
    if (!$this->mysqli->set_charset("utf8")) { // какие-то настройки БД, например установка кодировки
        printf("Error loading character set utf8: %s\n", $mysqli->error);
    }
    return $this->mysqli;

/* Закрываем соединение, если вместо "public $mysqli" решим использовать "public $result"
  function __destruct() {
  $this->mysqli->close();
  }
*/
}
Вот проект одного класса для работы с некоторым объектом:

PHP:
<?php
require_once('dbconn.php');

class Article {
  $this->link = new DBConnection;

     function __construct ( $link, $table, $id ) { ... }

     public function SelectFromBase () { // какие-то действия по выборке из базы
        $row = $link->sql_query("SELECT * FROM `articles` WHERE `id` = '$id'", 'fetch_assoc');
        print_r($row);
     }
     public function WriteToBase ( ) { ... }
     public function ReadFromBase ( )  { ... }
     public function CheckInBase ( )  { ... }
     public function RemoveFromBase ( )  { ... }

}
?>
Правильно ли такое взаимодействие или есть варианты получше?

P/S: Наверняка, для тех кто имеет опыт работы с ООП такой вопрос покажется не самым умным, но меня он занимает и тормозит уже длительное время. Так-что буду очень признателен за любой дельный совет.
 

AnrDaemon

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

Balancer

Новичок
Прописывать параметры аутентификации в самом классе — плохая идея. Нужен внешний конфигуратор (config.php/config.ini). В классе-модели (Article в примере), по хорошему, указываем только класс соединения с БД (вообще бэкенд). И плюс к этому — отдельная точка входа, инициализатор. Которая распарсит конфиг и активирует загрузку класса Article (инициация БД в котором может выполнять или им, или загрузчиком — это уже в зависимости от архитектуры).

Для примера одного запроса к БД получается избыточно, но когда классов будут десятки и начнётся поддержка проекта с модификациями — то единственный приемлемый вариант.

А для одиночного запроса проще пользоваться готовыми orm-like решениями на Composer, типа respect/relational или лёгкие ORM:
http://www.schizofreend.nl/pork.dbobject/
https://github.com/bcosca/fatfree (Axon внутри)
http://redbeanphp.com/
http://j4mie.github.io/idiormandparis/
 

Страшный Злодей

Бывший член клуба (достало хамство).
Прописывать параметры аутентификации в самом классе — плохая идея. Нужен внешний конфигуратор (config.php/config.ini). В классе-модели (Article в примере), по хорошему, указываем только класс соединения с БД (вообще бэкенд). И плюс к этому — отдельная точка входа, инициализатор. Которая распарсит конфиг и активирует загрузку класса Article (инициация БД в котором может выполнять или им, или загрузчиком — это уже в зависимости от архитектуры).

Для примера одного запроса к БД получается избыточно, но когда классов будут десятки и начнётся поддержка проекта с модификациями — то единственный приемлемый вариант.

А для одиночного запроса проще пользоваться готовыми orm-like решениями на Composer, типа respect/relational или лёгкие ORM:
http://www.schizofreend.nl/pork.dbobject/
https://github.com/bcosca/fatfree (Axon внутри)
http://redbeanphp.com/
http://j4mie.github.io/idiormandparis/
Большое спасибо, что откликнулись, но похоже вынужден извиниться, так-как не совсем понимаю терминологию. Что касается внешнего конфигуратора, так вроде файл dbconn.php и есть он самый, ну разве имя только не такое очевидное как config.php/config.ini? Относительно указания класса соединения с БД в классе Article, мне казалось, что строка "$this->link = new DBConnection;" именно это и делает. Ну и по поводу отдельной точки входа "инициализаторе", которая должна распарсить конфиг и активизировать загрузку класса Article, вы имеете в виду инициализирующий скрипт, который будет считывать конфиг соединения с БД, а затем вызывать класс Article, передавая последнему в параметрах линк на соединение с базой?
 
Последнее редактирование:

Страшный Злодей

Бывший член клуба (достало хамство).
Обычный совет в таких случах - взять готовый фреймворк и разбираться на примерах.
Не столько ответ, сколько посыл, но за участие спасибо! Примеры смотрел разные, логика в них не всегда очевидна. Хочется таки не копипастить, а понимать..
 

fixxxer

К.О.
Партнер клуба
Ну не Доктрину же человеку с нуля предлагать.
Это не причина окунать человека в дерьмо. С такими примерами говнокода он только еще больше запутается.
Или есть что-то проще и доступнее?
По последней твоей ссылке похоже на что-то нормальное (снаружи, по крайней мере). В Laravel-овском Eloquent тоже ничего сложного нет. Или вот, например, DataMapper на основе Eloquent.
 
  • Like
Реакции: WMix

Страшный Злодей

Бывший член клуба (достало хамство).
Спасибо почитаю, должно быть познавательно. По поводу ОРМ/DBAL/Common/Doctrine и прочее, на данном этапе, для меня ещё штуки не очевидные. Я сейчас лишь пытаюсь убедить самого себя в полезности ООП, а все эти доктрины, звучат для моих ушей, как ещё одна мутная абстракция над такой же непонятной абстракицей. Вижу, что куча людей пишет на ООП и очень этим довольны, но в мою голову это ещё не вместилось, надеюсь поместится.
 
Последнее редактирование:

fixxxer

К.О.
Партнер клуба
Спасибо почитаю, должно быть познавательно. По поводу ОРМ/DBAL/Common/Doctrine и прочее, на данном этапе, для меня ещё штуки не очевидные. Я сейчас лишь пытаюсь убедить самого себя в полезности ООП, а все эти доктрины, звучат для моих ушей, как ещё одна мутная абстракция над такой же непонятной абстракицей. Вижу, что куча людей пишет на ООП и очень этим довольны, но в мою голову это ещё не вместилось, надеюсь поместится.
Там по ссылке пример построения ООП-фреймворка на уровне приложения, не трогая вопрос моделей и персистенции - это более однозначный вопрос и более легкий для понимания, в том числе и принципов ООП.

А с обсуждением ORM мы тут традиционно быстро все скатимся в холивор Data Mapper vs. Active Record и на тебя ваще забьем, бгг. :D

Фаулеровские Refactoring... и PoEAA почитай еще потом, там объясняется не только как, но и зачем. Халявную pdf-ку найдешь небось уж.
 

Absinthe

жожо
Страшный Злодей, почитай Шлосснейгла, а то твой код ужасен даже без учёта присутствия-отсутствия ООП.
Не надо, эта книга устарела.
Есть другие, например Modern PHP. New Features and Good Practices или PHP Objects, Patterns, and Practice.

Поддерживаю http://fabien.potencier.org/article/50/create-your-own-framework-on-top-of-the-symfony2-components-part-1
На хабре есть русский перевод.
 
  • Like
Реакции: AmdY

AmdY

Пью пиво
Команда форума
Absinthe, ага, хорошая книга, только и шлосснейгл не устаревает, там очень много вкусняшек.
 

AmdY

Пью пиво
Команда форума
Absinthe, молодой человек, за кого вы меня принимаете, естественно, я знаю это, статьи фабьена давно прочитал, а книгу как попала ко мне 25 февраля, в тот же день. Книга отличная, но хипстерская и людям с неокрепшими знаниями лучше её читать _после_ шлосснейгла. А то сейчас все знают как решать архитектурные проблемы, а вот с сутью самих проблем и что когда применять не знакомы. Например, трейты и анонимки для незнакомых с ООП не только бесполезны, но даже опасны.
 

Страшный Злодей

Бывший член клуба (достало хамство).
Страшный Злодей, почитай Шлосснейгла, а то твой код ужасен даже без учёта присутствия-отсутствия ООП.
AmdY, а Вы не правы. Такие понятия как "прекрасен" или "ужасен" весьма субъективны. Обоснуйте свое утверждение. Что Вы имеете в виду, когда пишите "код ужасен"? Кому-то нравится перенос фиговых скобок на новую строку, а кого-то (например меня) раздражают вертикальные файловые простыни с кучей лишних строковых переносов. Кто-то требователен даже к тому, чтобы выводы ошибок были унифицированы, а кому-то оно менее чем равнозначно. Собственно, по делу бы лучше высказывались...

Я сто лет на форум не заходил, именно от того, что как-то напряженно здесь с уважительным отношением к собеседнику и с реальной помощью. Почему нам так важно выкатить напоказ ЧСЗ, вместо того, чтобы с радостью помочь кому-либо? ИМХО, совковые это комплексы и пережитки. Знаете, очень похоже на дорожное хамство автомобилиста, чем хуже авто, тем агрессивнее и хамоватее ведет себя люмпен. По моим наблюдениям, уже после какой-нибудь бюджетки типа тайотакамри, народ начинает проявлять свою культуру и цивилизованность. Повторюсь, это мое личное ни кому не навязываемое мнение, но дабы не быть голословным, вот пример того, как могло бы происходить общение на этом форуме. Обратите внимание, каким образом происходит посыл на Coding Style Guide

P/S: о книге, если вы о "профессиональное програмирование на PHP", то с ней ознакомился ещё лет 8 назад. К сожалению, не для моего среднего ума, слишком унылая и неубедительная (для меня конечно). Были и другие Энди Гутманс и ко, Мэтт Зандстра и т.д... От корки до корки такие книги читать не могу, только под конкретные задачи. Может быть из-за того, что программирование, это скорее мое любимое хобби, а не професиия. Да и образование моё не техническое, а гуманитарное. Так-что делайте скидку на разницу менталитета, иногда мы видим вещи по разному.
 

Absinthe

жожо
Absinthe, молодой человек, за кого вы меня принимаете, естественно, я знаю это, статьи фабьена давно прочитал, а книгу как попала ко мне 25 февраля, в тот же день. Книга отличная, но хипстерская и людям с неокрепшими знаниями лучше её читать _после_ шлосснейгла. А то сейчас все знают как решать архитектурные проблемы, а вот с сутью самих проблем и что когда применять не знакомы. Например, трейты и анонимки для незнакомых с ООП не только бесполезны, но даже опасны.
Modern PHP. New Features and Good Practices
и
PHP Objects, Patterns, and Practice

это 2 разные книги.
 
  • Like
Реакции: AmdY

fixxxer

К.О.
Партнер клуба
Страшный Злодей, в данном случае вполне объективно, на code review под каждой второй строчкой были бы комментарии с претензиями. Я потому ссылки и дал - посмотри, как опытные люди делают пошагово, вникнешь, сам увидишь что не так - тут вопрос опыта. Ты главное лично не воспринимай, "твой код фигня" не есть "ты дурак" вовсе, это как на преподавателя обижаться за то что двойку поставил. А что тут без политесов - так уж тут принято, в этом есть и своя прелесть =)
 
Статус
В этой теме нельзя размещать новые ответы.
Сверху