- Ещё дополню, что почему не стал использовать вариант с получением условно по име, Вервер (?), 12:10 , 11-Фев-23 (1) +8 [^]

- eval и иже с ним плохи в первую очередь из-за того, что в них поступает непровер, Аноним (3), 16:07 , 11-Фев-23 (3) +6 [^]

- Вот этот вариант подойдёт как решение наполовину если вы это будете делать не в, Аноним (10), 05:00 , 12-Фев-23 (10) +4

- Потому что условно в БД хранится тип объекта к примеру число objType , и мне чт, Вервер (?), 08:59 , 12-Фев-23 (12) +6 [^]

- А оно надо Кто пользователь ORM - программист или внешний пользователь, который, Аноним (18), 13:56 , 15-Фев-23 (18) +3

- Пользователь ORM - получается программист, т е Я Она типа ORM, хотя конечно н,
Вервер (?), 19:25 , 15-Фев-23 (21) +2 > А оно надо? Кто пользователь ORM - программист или внешний пользователь, который > про эти имена классов вообще знать ничего не должен?Пользователь ORM - получается программист, т.е. Я. Она (типа ORM, хотя конечно нет) для построения логики с сущностями которые реализуют объекты в приложении. Но в любом случае неважно должен внешний пользователь знать про имена классов или нет, как для "динамического" варианта я должен соотнести objTypeID из базы с именем класса, чтобы выполнить итоговою строку
$objItem = new $objClassName(); ? Варианта вижу 2: Или в коде формировать связь objTypeID => objClassName, т.е.
$objTypeData = [ Doc_Dogovor::OBJ_TYPE => 'Doc_Dogovor', Doc_Pismo::OBJ_TYPE => 'Doc_Pismo', ]; ...... $objItem = new $objTypeData[$objTypeID]();
Либо в самой БД хранить не objTypeID - а сразу имя класса, но вроде это совсем грязь, хранить куски кода в БД. Или я чего-то не понимаю?
- gt оверквотинг удален Дяденька, а зачем вы диспатчите типы через enum, как буд, Аноним (3), 16:03 , 11-Фев-23 (2) +4

- А это вам как зайдёт, вот вы изобрели в пхп типы данных из хаскеля - осваивайте,, Аноним (3), 16:13 , 11-Фев-23 (4) +5

- сделай обычный class Document От него наследуются class Dogovor и class Pismo , Аноним (52), 07:01 , 12-Фев-23 (11) +5

- Фабричный метод с маппингом - подход имеющий право на жизнь Вопрос в том, для ч, Аноним (15), 18:55 , 12-Фев-23 (15) +8 [^]

- Не хотел в нудные подробности углубляться, но если это поможет пониманию и оконк,
Вервер (?), 19:57 , 15-Фев-23 (24) +3 > Фабричный метод с маппингом - подход имеющий право на жизнь. Вопрос в > том, для чего это применять. > Очевидно, что у вас есть некая универсальная форма, которая посылает ид типа > создаваемого документа. И дальше вы создаете документ исходя из его ид. > И в базу потом пишете с тем же самым ид. > Вместо этого можно для каждого типа документа сделать свои формы, тип создаваемого > документа разруливать по маршруту обработчика, ид для базы держать в константе > класса и работать с ним только при записи в базу - > то есть, в контроллере вообще никогда.Не хотел в нудные подробности углубляться, но если это поможет пониманию и оконкретит что главное как лучше это реализовать, то вот, опишу более полно и близко к оригиналу: Есть такая сущность, как Статья. Это сущность из которой будет формироваться условно страница с самой этой Статьёй:
//Отображение её в БД TABLE Article ( id SERIAL PRIMARY KEY, title CHAR(20) NOT NULL )
Статья состоит из кусков разных типов объектов - Частей Статьи.
//Отображение Частей Статьи в БД TABLE ArticleParts ( id SERIAL PRIMARY KEY, artID BIGINT UNSIGNED NOT NULL, partType TINYINT UNSIGNED NOT NULL, partOrder TINYINT UNSIGNED NOT NULL, FK(artID) => Article(id) )
Так вот поле partType - это как раз тот самый objTypeID по которому мы понимаем Часть Статьи какого типа это:
//Общий предок Частей Статьи Class ArticlePart { const PART_TEXT; //Чисто текстовый блок const PART_IMG_GALLERY; //Набор картинок в блоке const PAT_POLL; //Блок с голосованием ....... //Получить объект нужного типа static public & getPartObjByType($objType){ $objItem = false; switch($objType){ case ...: $objItem = ....; break; .... ...... } } } //Классы самих Частей Статьи Class ArticlePart_TEXT extends ArticlePart { static const OBJ_TYPE = ArticlePart::PART_TEXT; //У каждого вида Части Статьи свой способ оформления в БД, //со своими таблицами и связями и пр. public function DB_Save(){ ..... } //Тут к примеру у каждого вида Части Статьи своя генерация HTML под него public function getHTML(){ ..... } }
И условно статью предполагается создавать из таких вот блоков разных типов. Они могут быть интерактивными, каждый из блоков, со своей связанной с пользователем информацией и пр. А уже как у статьи в общем может быть там пагинация и прочая херня. Короче велосипед, но мой и хочу чтобы колёса сразу квадратными не выбирались :)
- Вроде понятно У вас контроллер компонует результаты дочерних контроллерчиков М,
Аноним (25), 13:26 , 16-Фев-23 (25)Вроде понятно. У вас контроллер компонует результаты дочерних контроллерчиков. Можно имена классов просто в базу сохранять, без искусственных partType. Выборок по этим ид нет же?
- Блин Ну вот сама принципиально идея сохранять имена классов в БД Ну т е у,
Вервер (?), 21:17 , 16-Фев-23 (26) +1 > Вроде понятно. У вас контроллер компонует результаты дочерних контроллерчиков. Можно имена > классов просто в базу сохранять, без искусственных partType. Выборок по этим > ид нет же?Блин... Ну вот сама принципиально идея сохранять имена классов в БД... Ну т.е. условно есть скептическое отношение к языку basic, оператору goto, к использованию непроверенного пользовательского ввода во всякого рода SQL-инъекциях, к использованию конструкции eval, не является ли использование данных из БД в качестве исполняемого кода - плохой практикой? Ведь если в БД хранится имя класса, то мы должны использовать что-то типа:
$objItem = $stringFromDB(); . Т.е. как я вижу это - есть концепция "динамического кода", когда сам код программы - неясен на момент исполнения, и во время него более того тоже меняется. Т.к. в процессе исполнения получается сам код программы становится результатом его работы. А есть условно "статический код", т.е. в ближайшем приближении - код который можно скомпилировать в исполняемый файл и запустить сам по себе. Всякие eval() и $objFromString() вроде бы представляют собой часть динамической составляющей. Вот я и хочу разобраться, насколько это имеет смысл. Я так понял, что среди плюсов динамического подхода: Проще реализация - исключаем часть "конечного автомата по выбору класса для Объекта" Минусы у динамики - Смешение кода и данных, т.к. код для создания объекта берётся в любом случае из внешнего источника (БД или Роутинг из URL), также я думаю к минусам можно отнести скорость исполнения (если динамически инклудить файлы с описанием класса для Объекта) Плюсы и минусы у Статики - соответственно противоположные. Так ли это? Какие ещё есть варианты реализации таких вот как Товарищ выше описал "Контроллеров" и их "Контроллерчиков"?
- Вы можете туда интерфейс сохранять, а не конкретный класс И через DI контейнер ,
Аноним (25), 13:42 , 17-Фев-23 (27) +1 > Блин... Ну вот сама принципиально идея сохранять имена классов в БД...Вы можете туда интерфейс сохранять, а не конкретный класс. И через DI контейнер получать конкретную реализацию. Это вот именно то, что вы хотите в плане поведения, на самом деле. Айдишки искусственны, удобства от них имеют косвенный характер. Будь у вас документо-ориентированная БД и вам бы в голову не пришло их использовать. Хранить в базе код и эвалом исполнять - это фактически serverless концепция, вроде AWS Lambda. Так тоже можно! Любые извращения возможны. Если вам доставляет разбираться в этих концепциях, писать свои реализации - это одна история. Если нужно сделать, чтобы работало (и забыть) - другая. Я подозреваю, что необходимости что-то делать с кодом у вас вообще нет.
- Пожалуйста объясните, что такое DI контейнер Просто пример в несколько строчек ,
Вервер (?), 21:15 , 17-Фев-23 (28) +1 > Вы можете туда интерфейс сохранять, а не конкретный класс. И через DI > контейнер получать конкретную реализацию. Это вот именно то, что вы хотите > в плане поведения, на самом деле.Пожалуйста объясните, что такое DI контейнер? Просто пример в несколько строчек для иллюстрации. Я абсолютно не понимаю, о чём речь. > Я подозреваю, что необходимости что-то делать с кодом у вас вообще нет. Ну как... Поддерживать его, развивать логику и функционал на основе этой "фабрики объектов". Это, если я правильно понял суть реплики, не просто код для изучения концепции с теоретической целью. Цель вполне себе ясная, а этот вопрос встал на этапе реализации некоторых сущностей.
- На пальцах - это штука, которая знает, как инстанцировать объект указанного вами,
Аноним (29), 14:59 , 20-Фев-23 (29)> Пожалуйста объясните, что такое DI контейнер? Просто пример в несколько строчек для > иллюстрации. Я абсолютно не понимаю, о чём речь.На пальцах - это штука, которая знает, как инстанцировать объект указанного вами класса, чтобы вы могли не заниматься этим в своем коде. Дергаете ее либо вручную, либо она автомагически создает для вас объекты в аргументы методов ваших классов. https://laravel.com/docs/10.x/container https://symfony.com/doc/current/components/dependency_inject... > Ну как... Поддерживать его, развивать логику и функционал на основе этой "фабрики > объектов". Это, если я правильно понял суть реплики, не просто код > для изучения концепции с теоретической целью. Цель вполне себе ясная, а > этот вопрос встал на этапе реализации некоторых сущностей. Вы могли бы взять любой из фреймворков, где уже все есть, и не создавать собственные реализации, эволюционируя от более примитивных концепций к более продвинутым. Процесс увлекательный, не спорю.
- Надо не играть в бабу Вангу и чётко спросить В чём смысол поделки, самопальная O,
Аноним (18), 14:01 , 15-Фев-23 (20) +6 [^]Надо не играть в бабу Вангу и чётко спросить:>Я тут пишу свои всякие поделки В чём смысол поделки, самопальная ORM?

- Нет, смысл самой поделки не ORM, смысл того что я спрашиваю - некое подобие ORM,,
Вервер (?), 19:30 , 15-Фев-23 (23) +6 [^]> Надо не играть в бабу Вангу и чётко спросить: >>Я тут пишу свои всякие поделки > В чём смысол поделки, самопальная ORM?Нет, смысл самой поделки не ORM, смысл того что я спрашиваю - некое подобие ORM, но оно не самоцель, а лишь часть в моей общей замути. Спрашиваю, чтобы на этапе пока не накодил много объектов выбранным (и опробованным) способом который в вопросе и описал, и не пришлось потом всё перелопачивать из-за того, что выбранный способ унылый.
|