Здравствуйте, Sinclair, Вы писали:

T>>Может и тупик, но проблема эта — не проблема ORM. Это проблема языков, которые требуют на любой чих делать отдельный класс.
S>Нет. Это проблема — именно ORM. Потому что без ORM мы на тех же языках работаем с рекордсетами, которые не требуют порождать по классу на запрос. И прекрасно биндим их хоть в UI, хоть в бизнес-логику.

Это ограничения языков, где "класс" — это что-то занимающее месте в релизе.
В компиллируемых языках типы стираются.
Будь хоть миллиард классов — в выходном бинарнике их нет.


S>ORM претендуют на какую-то помощь, которой по факту не оказывают.

Как раз в бизнес-логике оказывают по принципу "типизированного рекордсета", чтобы к полям обращаться типизировано и по проверяемому компилятором идентификатору, а не через строковую константу.

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

Здравствуйте, Sinclair, Вы писали:

T>>Может и тупик, но проблема эта — не проблема ORM. Это проблема языков, которые требуют на любой чих делать отдельный класс.
S>Нет. Это проблема — именно ORM. Потому что без ORM мы на тех же языках работаем с рекордсетами, которые не требуют порождать по классу на запрос. И прекрасно биндим их хоть в UI, хоть в бизнес-логику.

Это ограничения языков, где "класс" — это что-то занимающее место в релизе.
В компиллируемых языках типы стираются.
Будь хоть миллиард классов — в выходном бинарнике их нет.


S>ORM претендуют на какую-то помощь, которой по факту не оказывают.

Как раз в бизнес-логике оказывают по принципу "типизированного рекордсета", чтобы к полям обращаться типизировано и по проверяемому компилятором идентификатору, а не через строковую константу.

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