PHP-дизайн для объектно-ориентированной сериализации базы данных: инициализация базы данных и статические функции-членыPhp

Кемеровские программисты php общаются здесь
Ответить
Anonymous
 PHP-дизайн для объектно-ориентированной сериализации базы данных: инициализация базы данных и статические функции-члены

Сообщение Anonymous »

Это всего лишь выстрел в темноту, но я кодирую себя в огненном водовороте гибели. У меня есть платформа электронной коммерции, которая «работает», и я пытаюсь улучшить ее и упростить управление, преобразовав ее в серию классов, которые «сериализуются» в базу данных MySQL. Итак, у нас есть class_order, class_customer, class_product и т. д. Одна из основных вещей, которые мне нужно реализовать, — это метод «преобразования», который будет читать существующую (очень плоскую и противную) схему базы данных и переформатировать все в эту хорошую новую реляционную схему O-O. Таким образом, я встроил создание таблицы в каждый отдельный класс вместе с соответствующей таблицей отношений. Например:

Код: Выделить всё

public function create_table() {
$q = "`id` BIGINT UNSIGNED NOT NULL AUTO_INCREMENT,
`type` SMALLINT NULL,
`value` decimal(6,2) DEFAULT NULL,
`usage_count` int null,
CONSTRAINT code_unique UNIQUE (discount_code)";
$ret = $this->actually_create_table($q);
return $ret;
}
Мне кажется, что это отличный способ документировать код внутри себя.
Проблема в том, что в моем коде «трансформера» мне приходится по очереди создавать экземпляры каждого класса: сначала с пустыми данными, чтобы сгенерировать схему с помощью метода create_table(), а затем просто перебирать все записи и позволять новому коду выполнять всю свою магию. Эта первоначальная настройка «инициализация с пустыми данными, затем вызов create_table()» — это скучно, но «хорошо», за исключением случаев, когда я начал реализовывать проверки данных инициализации. Например, если вы передаете данные клиенту без адреса электронной почты, давайте создадим исключение, поскольку нам не нужны эти данные в базе данных. Итак, теперь я взломал код своего преобразователя, если только я не дам ему «настоящие» данные, а затем просто не «сохраню» их. Это, вероятно, сработало бы, но это не очень удобно для CLoOj.
Затем я начал пытаться сделать эти методы статическими, чтобы избежать создания экземпляров. Что ж, это приводит меня к тому, что мне приходится статифицировать множество других методов и данных, и в конечном итоге я упираюсь в стену, например, с моим родительским классом БД, который имеет все связанные с БД вещи (например, метод fact_create_table()), которые нужны всем этим классам, включая созданный экземпляр $pdo члена, который obvz не может быть статическим.
Сейчас я просто застрял и задаюсь вопросом, решил ли кто-нибудь подобную проблему дизайна, потому что поиск в intarwebs имел безрезультатно.

Подробнее здесь: https://stackoverflow.com/questions/797 ... on-and-sta
Ответить

Быстрый ответ

Изменение регистра текста: 
Смайлики
:) :( :oops: :roll: :wink: :muza: :clever: :sorry: :angel: :read: *x)
Ещё смайлики…
   
К этому ответу прикреплено по крайней мере одно вложение.

Если вы не хотите добавлять вложения, оставьте поля пустыми.

Максимально разрешённый размер вложения: 15 МБ.

Вернуться в «Php»