kastaneda | Про дырявые абстракции на примере ORMов

propel:
  products:
    _attributes:  { phpName: Product }
    id:           ~
    name:         { type: VARCHAR, size: '40', required: true }
    stock_count:  { type: INTEGER, required: true }
    price:        { type: INTEGER, required: true }

class Product extends BaseProduct {
  public function getStockValue() {
    return $this->getStockCount() * $this->getPrice();
  }
}

Когда можно будет без лишних заморочек сделать SELECT * FROM products ORDER BY getStockValue() — вот тогда-то и наступит рай земной, коммунизм и вендокапец. А пока, увы, всё с ORMами грустно.

Flat | Top-Level Comments Only

From:

egorfine.livejournal.com

Рекомендую сменить отношение к ORMам. Да, они все сосут в разные стороны, но все-таки лучше поменять к ним свое отношение.

From:

fester-ua.livejournal.com

А благородный дон не считает, что регулярно (да какое "регулярно", часто!) вычисляемая функция getStockValue() должна лежать в базе данных в виде значения, которое меняется на каждом апдейте?

From:

kastaneda

О, это если оно часто вычисляется — то мы можем сделать view с такой вот колонкой. Но тогда становится не совсем понятно, зачем нам может потребоваться определять такую логику в соответствующем классе объекта! Нет бизнес-логики в классе — класс становится просто инструментом для загрузки/сохранения данных в базу (как на мой вкус, в этом случае ActiveRecord — не самый выразительный вариант).

А если у нас таких вот функций стопицод, и все они уместны? Если, чёрт его дери, у меня действительно сложная логика, а я чайник и не знаю тонкостей SQLя и конкретной данной СУБД? Мне кажется, в таком случае ORM был бы действительно в тему.

From:

kastaneda

Принципиальный момент: в большинстве современных ЯП я не могу взять функцию и разложить её на составляющие. Лучшее, что породила идеология ORM — это некий мета-код, который является для библиотеки ORMа данными, но легко переходит в исполняемый код как на хост-машине, так и на стороне БД.

Вот пример: для Propel'а у меня есть класс Criteria, в который я могу некими неуклюжими методами напихать сравнения, примерно вот так:

$crit = new Criteria();
// ProductPeer::doSelect($crit) выполнит SELECT * FROM product

$a = $crit->getNewCriterion(ProductPeer::PRICE, 100, GREATER_THAN);
$b = $crit->getNewCriterion(ProductPeer::STOCK_COUNT, 10, LESS_EQUAL);
$a->addAnd($b);
$crit->add($a);
// ProductPeer::doSelect($crit) выполнит SELECT * FROM product WHERE (price>100) AND (stock_count<=10)

Вся суть этой неуклюжей Criteria — управляемость в контексте библиотеки ORMа. Это можно разложить на кусочки, которые можно транслировать в SQL. А ещё из этой фигни можно вытрясти что-то полезное (для ORMа) — ну там, список упоминающихся полей, например (если они вдруг понадобятся).

Вот если бы можно было разложить на token'ы уже существующую ф-цию, а потом эти token'ы выразить в SQL… Увы, это возможно только в тех языках, где код является данными; то есть тебе с Lisp'ом такое теоретически возможно, а в обычных языках — хрен там.