LINUX.ORG.RU

Неконсистентность работы с базой во фреймворках

 ,


0

1

Объясните почему в симфони и ларавеле запрос данных из через орм и через обращение к базе дают разные типы результатов.

\App\Model::all()-> коллекция

DB::Table('model_table')->where(...)->get() массив

$repo->findBy() массив

$ent->getChildren() коллекция

В чем логика? Почему нельзя сделать чтобы возвращаемые данные были одного типа?

★★★

Последнее исправление: Jaberwock (всего исправлений: 1)

Напиши свой фреймворк и возвращай те типы, которые хочешь.

NeverLoved ★★★★★
()

Ибо говнокод правит php. Бросай его и бери что-то более адекватное.

th3m3 ★★★★★
()

добро пожаловать в laravel

anonymous
()

$ent->getChildren()->toArray(), Люк. Там коллекция - всего лишь обертка над массивом с реализацией метода ArrayCollection->matching, который фильтрует коллекцию по Criteria. +на месте коллекции может быть Proxy объект, так что решение вполне нормальное. Ты какие-то глупые вопросы на ровном месте задаешь. Посмотрим, как у тебя крышу снесет, когда ты во фреймворк форм симфони заглянешь=)

nguseff
()
Ответ на: комментарий от nguseff

С формами у меня было только одно неудобство. form type Entity и form type Collection при применении к большим коллекциям выедают много памяти, что легко обходится но оставляет осадок от несовершенства фреймворка.

По поводу твоего ответа я бы предпочел ArrayCollection ($repo->findBy() ), но думаю что это должно быть сделано на уровне фреймворка.

Сейчас начал смотреть ларавель. Надеялся что он будет меньше симфони, но все части будут подогнаны и сразу натыкаюсь на то же странное поведение, что и в симфони.

Jaberwock ★★★
() автор топика

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

x3al ★★★★★
()
Ответ на: комментарий от Jaberwock

А ArrayCollection ($repo->findBy()) Оно действительно надо? Ты посмотри на интерфейсы ArrayCollection. Он просто реализует интерфейсы, чтобы вести себя как массив php, больше там ничего нет (кроме того же matching, но зачем после запроса, ещё раз фильтровать результаты уже в памяти).

В Симфони есть ещё возможность работать с ORM Propel, можешь его посмотреть.

nguseff
()
Ответ на: комментарий от Jaberwock

Я не знаю как в php, но любая приличная ORM должна уметь отдавать более низкоуровневый результат на случай, когда тебе нафиг не нужны объекты (например, ты хочешь без обработки выплюнуть это в json). Или ты сейчас про другое?

x3al ★★★★★
()
Ответ на: комментарий от nguseff

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

$repo->findBy() это запрос данных и $ent->getChildren() запрос данных в чем разница?

Jaberwock ★★★
() автор топика
Ответ на: комментарий от Jaberwock

ArrayCollection в Doctrine это как массив, только хуже массива. Можно итерировать, обращаться по индексу, но функции работы с массивами PHP недоступны для объектов. А $ent->getChildren возвращает коллекцию потому, что иначе никак.

Сделать все результаты запросов одинаковыми нельзя, потому что они не одинаковые. Максимум, на что ты можешь рассчитывать, это то, что по ним можно будет итерировать (что в случае с Doctrine ты и так имеешь). Если сделать их одинаковыми, то это приведет только к усложнению абстракций и неочевидному поведению.

Если тебе нужны какие-нибудь крутые абстракции над условными коллекциями, бери другие библиотеки специально для этого предназначенные. ORM не должна это реализовывать, а в PHP из коробки этого нет.

nguseff
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.