Когда использовать ORM фреймворки?

[caballero]

большая часть предлагаемых прокладкой "решений" замечательно реализуется в базе, и использование прокладок вызвано скорее неумением использовать средства СУБД.

есть одна тонкость - не следует размазывать бизнес логику по проекту. Если юзаем хранимки то тогда логика там - а у нас тонкий клиент. Так писали 20 и больше лет назад .

Но если у нас приложение по сути трехзвенное (браузер- сервер- СУБД) то лучше бизнес-логику сосредоточить в программном коде. Тем более что мускул на простых линейных запросах работает быстрее чем на сложных с кучей таблиц

 

[Духовность™]

я огрызаюсь не на замечания а на наезды местной гопоты возомнившей себя програмистами

по моему, чуваку все же пора в РО. уже вторая тема с его участием перерастает в тупой флейм.

 

[varan]

Народ, просто выучите SQL - все вопросы отпадут сами собой

Ты реально думаешь, что ты единственный здесь, кто знает SQL?

 

[caballero]

по моему, чуваку все же пора в РО. уже вторая тема с его участием перерастает в тупой флейм

ну разумеется для тебя это флейм. Это как я бы попал на форум по медицине, например, или по юриспруденции.

Ты реально думаешь, что ты единственный здесь, кто знает SQL?

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

 

[Духовность™]

причем тут SQL?
Задача ORM - создать иллюзию хранения объектов в базе, инкапсулировать логику в объектах моделей, а не размазывать её по функциям.

		$user = new User();
		$user->setName('вася');
		$user->setAge('18-08-1984');
		$user->save(); // иммитация сохранения объекта  в базе
		$id = $user->id;
		
		// ... 
		
		$user = User::findById($id); // инкапсуляция бизнес-логики в рамках объекта
		$user->getAge()->getTextAge('Родился %d %m %Y'); // Родился 18 августа 1984 года
		$user->getZnakZodiaka(); // лев

Вот в этом задача ORM. Сделать красиво и упростить.

 

[Redjik]

Духовность™
только сделай __get и __set еще для обработки гетеров и сетеров
$user->age->TextAge

 

[caballero]

Задача ORM - создать иллюзию хранения объектов в базе, инкапсулировать логику в объектах моделей, а не размазывать её по функциям.

Верно. Но это в теории.

Например всю логику в объектах инкапсулировать не получится. В первую очередь выборки статистического характера для которых придется создавать псевдообъекты и псевдополя на объектах.
еще раз:
продажи товаров за месяц - шо сие такое за сущность. В товар она не вписывается. Либо псевдообъект ( и так на каждую выборку) либо псевдо поле на объекте товар и куча таких полей на каждую выборку (сколько продано за месяц, сколько продано по регионам, средняя цена и т.д.)
либо просто берем то что вернул ORM - тот же ассоциативный массив и выдаем на гора

кстати то что ты написал - обычный Active Record

 

[Духовность™]

Духовность™
только сделай __get и __set еще для обработки гетеров и сетеров
$user->age->TextAge

через __call это работает у меня

 

[varan]

продажи товаров за месяц - шо сие такое за сущность.

Ну а почему не в вести класс SalesAnalService, у которого будут методы getSoldByPeriod() и т.д. ? В чем, собственно, сложность не пойму

 

[Redjik]

через __call это работает у меня

точно =) ну я это и имел ввиду - спросоня.

 

[caballero]

только сделай __get и __set еще для обработки гетеров и сетеров

уточнаю
делается внутренний асоциативный массив
__get и __set
запихивают туда данные и читают

тогда получаем просто $user->name ='вася';
массив нужен для двух вещей
сериализации в сессию (динамические свойства не сериализуются)
инициализация объекта передачей обычного массива с fetch_array в конструктор (имплементация find() )
ну и соответствие полей объекта полям таблицы БД что весьма удобно и читабельно и исключает необходимость маппинга в XML или как там. Разумеется полям таблицы при этом надо давать вменяемые названия.
.

 

[caballero]

Ну а почему не в вести класс SalesAnalService, у которого будут методы getSoldByPeriod() и т.д. ? В чем, собственно, сложность не пойму

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

 

[Ragazzo]

LOL "специалист по высоконагруженным проектам" поднял настроение

 

[varan]

во первых такие классы придется создавать на каждую выборку на каждый репорт

Не на каждый репорт. На группу репортов. "сколько продано за месяц, сколько продано по регионам, средняя цена и т.д." - это всё могут быть методы одного класса. Возвращать они могут по-разному, или число, или объект класса "данные для графика" или что-то еще, что нужно.

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

Таких классов-сервисов "без сущности" в любом проекте полно. В них может быть мало методов или много - это уж как повезет.
Например, сервис отправки письма. Ты можешь назвать класс PochtaRossii, если тебе нужна именно сущность реального мира. Но вообще говоря и SendMailService тоже подойдет.
Так же как SalesAnalService можно переименовать в SalesAnalytic, тогда можно себе представлять чувака-аналитика, который выдает тебе инфу

 

[baev]

AnalService — это круто…

 

[Ragazzo]

baev
Пфф... я встречал людей, которые слово Button сокращали до butt, когда вешали свои колбеки.

 

[gerasim]

причем тут SQL?
Задача ORM - создать иллюзию хранения объектов в базе, инкапсулировать логику в объектах моделей, а не размазывать её по функциям.

		$user = new User();
		$user->setName('вася');
		$user->setAge('18-08-1984');
		$user->save(); // иммитация сохранения объекта  в базе
		$id = $user->id;
		
		// ... 
		
		$user = User::findById($id); // инкапсуляция бизнес-логики в рамках объекта
		$user->getAge()->getTextAge('Родился %d %m %Y'); // Родился 18 августа 1984 года
		$user->getZnakZodiaka(); // лев

Вот в этом задача ORM. Сделать красиво и упростить.

Имхо, пример никак не иллюстрирует ни "красоту", ни "простоту" ORM. Код приведенных методов можно написать и без ОРМа

 

[Духовность™]

Имхо, пример никак не иллюстрирует ни "красоту", ни "простоту" ORM. Код приведенных методов можно написать и без ОРМа

Жду пример кода данного кода без ORM.

 

[Redjik]

Кстати не стоит забывать еще и про lazyLoad связанных таблиц

 

[caballero]

AnalService — это круто…

лет после 40 еще и полезно в профилактических целях

Имхо, пример никак не иллюстрирует ни "красоту", ни "простоту" ORM. Код приведенных методов можно написать и без ОРМа

это AR а не полноценный ORM со связями таблиц и т.д. Тут как раз вменяемое исользование. Особенно для DML операций
которые в подавляющем числе случаев идут на одну таблицу