Ну вообще я потестил, время работы парсера ORM на 1000 запросов 0.05с с копейками, поэтому да, больший проигрыш сам DbSimple cо своим стремительно устаревающим расширением mysql дает.
Ну и на создание сущностей на больших объемах уходят ресурсы.
Люблю LS и люблю ORM'ы, но реализациия ORM в LiveStreet мне не по душе.
Первое, что я увидел когда смотрел ее — это то, что парсер запроса встроен в метод __call модуля а не в мэппера, что довольно странно в принципе, кроме того еще и перехватывает все обращения к другим модулям и проупскает через десяток RegExp'ов.
Во-вторых как движок БД используется не самый быстрый DbSimple, а помноженный еще и на парсер ORM'а он вообще не выдает ничего более-менее производительного.
Что касается ActiveRecord, как паттерна, выбранного для реализации, то тут, наверное, дело вкуса, хотя я был бы рад увидеть DataMapper на его месте.
Я сам сторонник ZF Coding Standart и не использую Венгерскую нотацию, но когда я пишу на\под LiveStreet я использую его «стандарты» кодирования.
Во-первых, потому что мне их подсказвыает IDE.
А во-вторых, потому что разноперые стили в одном проекте это еще хуже.
Ну и на создание сущностей на больших объемах уходят ресурсы.
Первое, что я увидел когда смотрел ее — это то, что парсер запроса встроен в метод __call модуля а не в мэппера, что довольно странно в принципе, кроме того еще и перехватывает все обращения к другим модулям и проупскает через десяток RegExp'ов.
Во-вторых как движок БД используется не самый быстрый DbSimple, а помноженный еще и на парсер ORM'а он вообще не выдает ничего более-менее производительного.
Что касается ActiveRecord, как паттерна, выбранного для реализации, то тут, наверное, дело вкуса, хотя я был бы рад увидеть DataMapper на его месте.
Во-первых, потому что мне их подсказвыает IDE.
А во-вторых, потому что разноперые стили в одном проекте это еще хуже.