Comments 12
Классная статья, и даже меня упомянули :) Спасиб!
Если честно, с REST в Symfony2 не работал, но реализация REST серверов на той же ноде в свое время просто поразила своей простотой. Может я не прав, но учитывая, что json это нативный формат для js, то таких проблем с сериализацией там впринципе нет. Не смотрели ли вы в сторону ноды?
Если честно, с REST в Symfony2 не работал, но реализация REST серверов на той же ноде в свое время просто поразила своей простотой. Может я не прав, но учитывая, что json это нативный формат для js, то таких проблем с сериализацией там впринципе нет. Не смотрели ли вы в сторону ноды?
> он “помешался” на версии 2.1, которая даже бета версии не имела
уже RC2 вышла даже
уже RC2 вышла даже
А кто-нибудь пользуется ORM Designer для описания моеделей?
«Проблемы» реально спорные.
1) Про зависимости в целом верно. Неплохо было бы разделить бандл и саму реализацию. Это проблема многих йоханесовских бандлов.
2) Подозреваю, что проблема с null и частичным обновлением как раз тесно связаны: в виде юзкейза обнуления nullable поля.
Однако с точки зрения библиотеки сериализации это 2 разных вопроса и, имхо, первое должно быть реализовано в каком-то виде (мало ли какие юзкейзы могут быть). Однако, это поведение должно быть опциональным и настраиваемым, что указанный PR не выполнял (что мешало написать нормальный — хз).
Что касается «частичного» обновления — это в общем стандартный вопрос наличия метода типа «merge». И вопрос нужен ли он в самой библиотеке сериализации или нет тоже хороший. Но, что-то PR я не вижу на эту функциональность…
1) Про зависимости в целом верно. Неплохо было бы разделить бандл и саму реализацию. Это проблема многих йоханесовских бандлов.
2) Подозреваю, что проблема с null и частичным обновлением как раз тесно связаны: в виде юзкейза обнуления nullable поля.
Однако с точки зрения библиотеки сериализации это 2 разных вопроса и, имхо, первое должно быть реализовано в каком-то виде (мало ли какие юзкейзы могут быть). Однако, это поведение должно быть опциональным и настраиваемым, что указанный PR не выполнял (что мешало написать нормальный — хз).
Что касается «частичного» обновления — это в общем стандартный вопрос наличия метода типа «merge». И вопрос нужен ли он в самой библиотеке сериализации или нет тоже хороший. Но, что-то PR я не вижу на эту функциональность…
Кирилл, в твоих словах есть доля истины.
>Что касается «частичного» обновления — это в общем стандартный вопрос наличия метода типа «merge». И вопрос нужен ли >он в самой библиотеке сериализации или нет тоже хороший. Но, что-то PR я не вижу на эту функциональность…
Было большое обсуждение этого вопроса, и все свелось к тому, что Бенжамин создал новый бандл.
Мы пробовали использовать merge, но это крайне неудобно было. Когда имеется десяток моделей, еще больше DTO, это слишком проблематично. Не покидает мысль, что ты пишешь рутинный и малополезный код, а в довесок, ты должен написать к нему еще и тесты. Я хочу писать код с удовольствием, а не вымучивать строчку за строчкой.
Так что действительно, проблемы маленькие, а последствия ощущаются значительные.
>Что касается «частичного» обновления — это в общем стандартный вопрос наличия метода типа «merge». И вопрос нужен ли >он в самой библиотеке сериализации или нет тоже хороший. Но, что-то PR я не вижу на эту функциональность…
Было большое обсуждение этого вопроса, и все свелось к тому, что Бенжамин создал новый бандл.
Мы пробовали использовать merge, но это крайне неудобно было. Когда имеется десяток моделей, еще больше DTO, это слишком проблематично. Не покидает мысль, что ты пишешь рутинный и малополезный код, а в довесок, ты должен написать к нему еще и тесты. Я хочу писать код с удовольствием, а не вымучивать строчку за строчкой.
Так что действительно, проблемы маленькие, а последствия ощущаются значительные.
И все-таки что мешает использовать нативный парсер json_encode/json_decode и поверх него наворачивать валидации, маппинги и прочее?
REST на Symfony2 ровно так же ка и реализация REST в Zend Framework и 1 и 2 версии — это очень большие тормоза, на которых теряется вся прелесть REST и поедает ресурсы вашего хостинга.
Безусловно, ваш код может быть полезен, когда по ТЗ в качестве фреймворка указан-а Symfony2
Но если это не обязательное условие посмотрите сюда, простой REST будет работать быстрее, приблизительно в 5-10 раз :):
luracast.com/products/restler/
www.slimframework.com/
Ну а если хочется достичь Дао, то как советовали раньше смотрите в сторону NodeJS:
mcavage.github.com/node-restify/
github.com/danwrong/restler
Безусловно, ваш код может быть полезен, когда по ТЗ в качестве фреймворка указан-а Symfony2
Но если это не обязательное условие посмотрите сюда, простой REST будет работать быстрее, приблизительно в 5-10 раз :):
luracast.com/products/restler/
www.slimframework.com/
Ну а если хочется достичь Дао, то как советовали раньше смотрите в сторону NodeJS:
mcavage.github.com/node-restify/
github.com/danwrong/restler
Можно и phalcon использовать, он будет еще быстрее. А еще лучше java. В php гнаться за скоростью отработки скрипта не всегда правильно, больше вероятность, что упретесь в работу с базой.
Во-первых, исторически так сложилось, что сначала было php4 на проекте, в итоге все было переписано на symfony2, затем медленно появился REST. Помимо него в проекте есть много консольных команд, админская часть, используется много библиотек, бандлов, как своих, так и чужих. В целом, фреймворк нам подходит
Во-первых, исторически так сложилось, что сначала было php4 на проекте, в итоге все было переписано на symfony2, затем медленно появился REST. Помимо него в проекте есть много консольных команд, админская часть, используется много библиотек, бандлов, как своих, так и чужих. В целом, фреймворк нам подходит
Sign up to leave a comment.
Сериализация объектов в json формат для реализации REST API