devclub.eu

IT-встречи в Таллине (на русском)

Видео: Александр Рудаков. PHP Enterprise Applications

Назад

Видео: Евгений Голобородько — Нет плохих технологий, есть плохие практики

Далее

Core Spring in Tallinn

6 комментариев

  1. W32Blaster

    Отличный доклад, посмотрел видео полностью. Не знал, что похапе уже так сильно подрос. Очень интересно теперь делают видео-презентации.

    Кстати, по содержанию. В последнем примере объект Olja имеет две связи, а Masha одну. Наверно потому что Olja.boobs_size = 5 в то время как Masha.boobs_size = 1 🙂

  2. Jevgeni Goloborodko

    Интересный доклад, только как-то забили упомянуть Symfony которая и породила Doctrine. И, кстати, утверждение о том, что Doctrine однозначно лучше чем Propel довольно спорно. Просто SensoLabs сейчас пропихивает свою технологию. Во всяком случае это актуально для версии 1.Х
    И я всётаки не понял каким образом весь этот микс технологий справляется с нагрузками? По идее чем больше прослоек — тем медленее система в целом (больше требухи подгружать для каждого запроса). Кэширование, конечно помогает, но не является панацеей. Ведь AOP, ORM и.т.д. созданы для быстрого девелопмента и удобной поддержки, а не для перформанса.

    • хехе 🙂 Женя, не тебе бы о _спорных_ утверждениях говорить :)))

      Александр наверное имел в виду что перформанса им хватает. врядли тут имелся в виду мега-нагруженный портал. в таких случая методики уже просто другие..

      • Jevgeni Goloborodko

        У меня вообще тема очень спорная. Только на поспорить времени не хватило 🙁
        Но с нетерпением жду всех холиварзиков в комментах к докладу 🙂

    • Alex Rudakov

      Не знал что к моему посту коменты есть :)))

      Ответ спустя два года:

      Doctine 2.0 лучше.

      Про перформанс:
      Пока код работает быстрее чем запросы к базе. Проблем не возникнет. Как правило даже с кучей прослоек запросы к базе/кешам/файловой системе занимют львиную долю времени запроса.

      А вообще какой бы не был медленный код, если его распаралелаить на n нод, где n = количество пользователей / количество пользователей, которое может обслужить одна нода, то проблем с перформансом не будет (за исключением централизованных БД).

      scalability != быстрый код
      scalability == способность кода масштабироваться

      ORM, DAO и AOP и другие прослойки какраз таки и упрощают распаралеливание т.к. не приходится менять код чтоб поменять технологию хранения данных или конфигурацию хранилища.

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

*

создано с помощью WordPress & Автор темы: Anders Norén