Как правильно наследовать и соединить классы?

Question

[Max Ba]

Ребят, не могу разобраться.
У меня есть три класса.
1) User (методы: создание, обновление, удаление) в mysql для пользователей отдельная таблица.
2) Organisation (методы: создание, обновление, удаление) в mysql для организаций тоже отдельная таблица.
3) Invoice (счета) (методы: создание, обновление, удаление) в mysql для счетов отдельная таблица, но содержит id_user и id_org.

Получается, что у меня третий класс Invoice грохнется, если я переименую какой-то столбец в таблицах пользователи или организации.

Я неправильно выделил сущности, или в чем причина?

Answer 1

[Александр]

У вас Invoice должен зависеть от объектов User и Organisation. Соответственно внутри Invoice вы работаете с параметрами переданных объектов.

$uid = $this->User->getId();
    $oid = $this->Organisation->getId();

Их нужно передать в конструкторе или отдельными методами. Код без комментов, ну уж очень не удобный тут редактор.

class Invoice
{
    protected $User;
    protected $Organisation;

    public function __construct(User $User = null, Organisation $Organisation = null)
    {
        if (!is_null($User)) {
            $this->setUser($User);
        }
        if (!is_null($Organisation)) {
            $this->setOrganisation($Organisation);
        }
    }
    public function setUser(User $User)
    {
        $this->User = $User;
    }
    public function setOrganisation(Organisation $Organisation)
    {
        $this->Organisation = $Organisation;
    }
}

Такой подход поможет вам получать дополнительные поля объектов User и Organisation и не переживать, что вы поменяете таблицу.

Comments

[Max Ba]

Понял. А что делать, если у меня в запросе на получение счета используется INNER JOIN в запросе? И например меня (или не меня) торкнуло изменить поле в какой-либо таблице?

[Александр]

Вообще - менять имена в таблицах, из которых собираются объекты - так себе затея. Вам в любом случае нужно будет переписать код всех классов для этих таблиц.

И да правильная настройка foreign key прям помогает не делать глупости )

Но если таки имена полей таблиц/таблицы переименованы приложение просто сломается.

[Max Ba]

public function getInvoice($id){
  $query = "SELECT * FROM `".$this->db_table_invoice."` AS t1 JOIN `".$this->db_table_user."` AS t2 ON t1.`user_id` = t2.`id` JOIN `".$this->db_table_org."` AS t3 ON t1.`org_id` = t23.`id` WHERE t1.`id` = ?";
  $stmt = $this->db->prepare($query);
  $stmt->execute(array($id));
  return $stmt->fetch();
}

Вот метод получения данных о счете. Видите, в нем связь таблиц. И этот запрос НЕЛЬЗЯ сделать не зная структуры БД.

[Александр]

Проблему которую вы описывает с успехом решают Eloquent и Doctrine. Эти инструменты достаточно сложны, чтобы не писать их с нуля ))

По сути единственный способ - это отдельно описать зависимости одних моделей от других. И собирать запросы с учетом этих зависимостей. Но даже если вы это сделаете - это не даст 100% защиты от дурака.

[Max Ba]

Александр, понял, спасибо!

[Александр]

Макс Васильев, в очень грубом приближении это будет выглядеть так:

1. Все модели нужно научить отдавать свои таблицы и поля;
2. Нужно запилить класс управления зависимостями - он же конструктор запросов. Преобразует определенный тип зависимости в определенный кусок запроса;
3. Когда будут готовы п.1 и п.2 нужно описать зависимости в классе Invoice, которые будут автоматически подтягивать имена полей таблиц и сами таблицы, если нужны;

Логика всего этого дела не тривиальна от слова совсем, и в комментариях на тостере её не описать. И то, это решение позволит локализовать проблему, но не избавиться от неё полностью. Классы, работающие с таблицами нужно будет изменять вместе с изменениями таблиц.

[Max Ba]

Александр, Мощно! Большое спасибо за объяснение)

Answer 2

[Therapyx]

А зачем Инвоису айди организации?
Юзер привязан к организации, счет привязан к юзеру. айди организации как foreign key должен быть у юзера, который пренадлежит какой-либо организации.
Конечно если ты взял счет как "association class", даже в этом случае почему должно что-то грохнуться? если ты сделаешь связь (забыл название, вроде каскад), то к примеру при переименовании организации, эти же операции должны апдейтнутся и в связующих операциях. Т.е. организация А, станет организаций Б как в столбце, где ты это переименовал, так же и в счетах и пользователях.
упд, а нет, все же каскад (on update cascade), значит еще что-то помню хД

Comments

[Max Ba]

Спасибо. Я в сообщении выше ответил про MYSQL запрос. Можешь глянуть?

[Therapyx]

Макс Васильев, ну что я могу тут сказать... Конечно может быть и придумали уже методики, как такого избежать. Но я на своей памяти такого не припомню.
Пэтому и надо относится к проэктировке проекта очень тчательно. Не просто так же говорят, что кодинг - это всего-лишь 10-30% от всего времени проекта. А если бы было так просто раааз и поменял архитектуру, то конечно все было бы легко))
Могу разве что посоветовать делать качественную документацию, чтобы при каких-либо изменениях можно было почитать, что надо изменить с этими изменениями. И я молчу уже о помощи "новым" разрабам. Эта касается так же и тебя, ибо ты через пол года- год забудешь об этом в первую очередь))

[Max Ba]

Therapyx, спасибо за объяснение. Я думал что я сильные сделал зависимости от БД. В общем разберусь как следует.

[Therapyx]

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