Крайне ок

[metaclass]

Comments

[udpn.livejournal.com]

Когда в следующий раз задумаете делать бессмысленные обёртки над говном, обращайтесь, дам тот же самый совет.

Однако, ормы повторяют функциональность эскюэля, а эскюэлю фабрики не нужны. Вопрос: нахуя?

[metaclass.livejournal.com]

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

[thinker8086.livejournal.com]

А вот кстати да, именно подобный пример пришёл в голову.

Можно, конечно, сказать, что "плохой дизайн", но оно вроде как просто и масштабируемо.

А как это делается в нормальных языках?

[metaclass.livejournal.com]

Во-первых, там разные реализации не нужны. В принципе. В контексте функциональных языков и иммутабельности "другая реализация записи из БД" - это безумие. Данные они и есть данные, если мы хотим с ними работать по другому - мы просто возьмем другие функции, если мы хотим полиморфизма - так он у нас и так есть, без объектов и классов.

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

[rashid80.livejournal.com]

Откуда такие глубокомысленные выводы о том что я пишу обертки? Речь шла о готовых ОРМах, которые иногда приходится использовать. Когда в другой раз захотите сделать вывод, подумайте. Делаю скидку на возраст - иначе это не объяснить ;)

ОРМы это прослойка между объектами и реаляционными СУБД. Местами это сильно ускоряет разработку, когда нет жестких требований к скорости работы.

[udpn.livejournal.com]

Делать != писать. Когда в следующий раз будете демагогией заниматься, убедитесь хотя бы, что делаете это верно.

Про ормы можете не рассказывать. Нажевался. Разработку они не ускоряют. На поле боя кроме ошибок дизайна SQL появляются ещё и ошибки дизайна орма.