PHP является одним из самых популярных языков программирования, а также недавний выпуск PHP 7 сделал его лучше и стабильнее, на стороне сервера, чем когда-либо.
PHP широко используется в крупных проектах. Facebook, например, использует PHP для сохранения и создания своих внутренних систем. WordPress использует PHP, чтобы оживить свои внутренности, которые в свою очередь приводят в движение более чем 26% сети. На сегодняшний день на PHP работают более 82% веб-сайтов.
В этой статье мы рассмотрим три самых популярных PHP фреймворка: Symfony, Laravel и Yii. Мы рассмотрим и сравним их, чтобы помочь вам решить, какой из них будет наилучшим образом подходить под ваши нужды.
Зачем нужен PHP фреймворк?
Какой смысл использовать фреймворк вместо чистого PHP для разработки приложения? Несколько преимуществ использования фреймворков:
Как выбрать PHP фреймворк?
Задайте себе пару вопросов ниже, они помогут вам в выборе:
Symfony, Laravel, и Yii
Прежде чем погрузится в технические подробности, вот краткий обзор претендентов:
Symfony
Symfony представляет собой набор повторно используемых компонентов PHP, что позволяет разработчикам создавать масштабируемые, высокопроизводительные приложения. Выбрать можно из 30 компонентов, разработчик имеет полную свободу экспериментировать и работать в среде RAD. Symfony API позволяют также легко интегрироваться с приложениями сторонних разработчиков, и он может быть использован с популярными фреймворками, такими как AngularJS.
Многие популярные проекты, в том числе Drupal и phpBB, также использовали Symfony. На самом деле, Laravel, самый популярный PHP фреймворк, это построен на Symfony.
Laravel
Laravel имеет отличное сообщество и опережает всех в списке наиболее популярных фреймворков. (Одиним из ведущих разработчиков Laravel на Livecoding.tv является Sfiskell.)
В мае 2015 года Laravel объявила, что версия 5.1 будет включать долгосрочную поддержку в течении двух лет. Версия 5.2 была представлена в декабре 2015 года. Многие хостинг компании предоставляют поддержку Laravel и предлагают хостинг решения для приложений на Laravel.
Yii
Yii является безопасным, быстрым, высокопроизводительный фреймворком для веб-разработки и разработки приложений. Yii использует менеджер зависимостей для PHP для обработки различных зависимостей и установок (подробнее об этом позже). Yii также является самым быстрым PHP фреймворком.
Еще одна интересная особенность Yii интегрирован с Jquery. Интеграция позволяет front-end разработчикам быстро охватить фреймворк. Подобно Symfony, Yii также использует компоненты, обеспечивающие быструю разработку приложений.
Как их сравнить
Все три фреймворка идеально подходят для создания веб-приложений 2.0, но каждый из них служит разным целям. Давайте посмотрим на их особенности.
Шаблонизаторы
Шаблонизаторы сводят к минимуму усилия разработчиков и обеспечивают лучшую функциональность.
Система шаблонов Symfony Twig
Twig это современный шаблонизатор для PHP. Symfony использует Twig в свою пользу и позволяет разработчикам писать чистый, лаконичный код с возможностью сделать больше, чем на чистом PHP. Например, он принимает следующий подробный код:
<?php echo $var ?> <?php echo htmlspecialchars($var, ENT_QUOTES, ‘UTF-8’) ?>
Twig делает то же самое со следующим кодом:
{{ var }} {{ var|escape }} {{ var|e }} {# shortcut to escape a variable #}
Узайте больше о Twig и его особенностях на официальном сайте.
Система шаблонов Laravel Blade
В отличие от других шаблонных систем, Blade позволяет использовать PHP код в представлениях. Весь код в представлении файлов превращается в чистый PHP во время обработки.
Система шаблонов Yii Default
Yii не использует каких-либо третих систем по умолчанию, но это не означает что ему не хватает поддержки системы шаблонов. Выбор системы шаблонов зависит от команды разработчиков. Symfony использует Twig, поэтому, если вы использовали Symfony в прошлом, вы захотите использовать Twig для вашего следующего проекта на Yii.
Здесь нет явного победителя. Все три фреймворка используют шаблонны для улучшения front-end разработки и технического обслуживания. Небольшое преимущество Yii является то, что фреймворк не имеет заранее определенную шаблонную систему.
Разница фреймворков
Symfony работает на повторно используемых компонентах и обеспечивает лучшую модульность. Symfony также использует модель и контроллер для разработки веб-приложений, который может выглядеть плохо для многих новых разработчиков, но это работает. Кроме того, Symfony является хорошим примером модульного фреймворка. Вы можете использовать 30 компонентов, предоставленных Symfony в проекте по модульному принципу.
Yii это MVC фреймворк. (Symfony действительно обеспечивает поддержку MVC, который обсуждается более подробно в Is Symfony2 MVC framework на сайте blog.sznapka.pl.)
Symfony может быть использован для быстрой разработки и сложных проектов. Несмотря на это, есть мнения о том что фреймворк лучше использовать для сложных проектов. Yii также использует компоненты, но не в качестве модульных как Symfony.
Если вы ищете модульный фреймворк, обратитесь к Symfony.
Загрузка
Эти три фреймворка имеют несколько процедур установки. Если вы используете composer для манипулирования пакетами, вы будете рады узнать, что все механизмы могут быть установлены с помощью composer.
Для Symfony, роль composer является более важной. Идею компонента обработки лучше всего реализовать с помощью менеджера зависимостей Composer PHP.
Существуют и другие способы установки соответствующих фреймворков. Например, вы можете установить фреймворк, используя простой метод архивирования.
После установки Yii предоставляет вам веб-приложение и шаблон для работы. Symfony2 также предоставляет демо-приложение, чтобы начать работу.
Laravel также легко установить с помощью composer create-project или с помощью Laravel Installer. Детальное руководство по установке Laravel.
Быстрая разработка
С точки зрения компании или клиента, очень важно быстро получить приложение на рынке для удовлетворения потребительского спроса. Symfony выделяется за то, что за ним прочная основа с сильным сообществом. Laravel быстро растет, но он еще не может считаться основным PHP фреймворком. С другой стороны, если у вас нет каких-либо знаний о PHP фреймворках и вы хотите начать работу как можно быстрее, рассмотрите Laravel. Laravel простой в плане обучения, вы найдете много учебников в интернете, которые помогут вам начать работу. В свою очередь Yii поднимает производительность на новый уровень.
Эффективность
Производительность любого приложения имеет значение только тогда, когда это в режиме реального времени приложение использует критически важные данные. Как много веб-приложений зависит от высокой производительности? Не так много, но производительность фреймворков может сыграть решающую роль во многих проектах.
Социальные сети являются ярким примером событий в реальном времени и один из наших топ стримеров, jadson, построил мобильную социальную сеть с помощью Yii2. Когда речь заходит о выборе наилучшей основы для создания приложения высокой производительности, Yii выделяется как самый быстрый PHP фреймворк.
Производительность Laravel является весьма дискуссионной темой. Он самый медленный, но имеет ли это значение когда в сети есть масса ресурсов для ускорения производительности, в том числе руководство на GitHub для ускорения Laravel приложений.
Поддержка баз данных
Symfony 2 обеспечивает лучшую поддержку баз данных. Вы можете работать с массивом баз данных, в том числе NoSQL и DynamoDB. Yii и Laravel также полезны, но они поддерживают меньше, чем базы данных Symfony. Поддержка баз данных каждым отдельным фреймворком отображена в таблице.
Сообщество и ресурсы
Залогом продолжительной жизни фреймворка с открытым исходным кодом является сила его сообщества. Все три фреймворка имеют сильные сообщества, хотя Symfony-х немного более зрелым в этом плане. Предсказать динамику развивития сообществ в будущем является сложной задачей.
Laravel документация
Symfony документации (3.0)
Yii документация
Сходства
Мы рассмотрели различия между фреймворками. Теперь давайте посмотрим на их сходства:
Все еще в раздумиях? Может быть, эти пункты помогут вам сузить круг:
Symfony:
Yii:
Laravel:
Вывод
Если сравнивать Symfony, Laravel и Yii, все три PHP фреймворка являются отличными вариантами, которые обеспечивают full-stack разработку. Но лично для меня, Laravel является победителем, который превращается в звезду.
Тем не менее, Symfony и Yii тоже отличные варианты. Symfony хорошо разработан и имеет более крупное, зрелое сообщество. Yii является надежным, безопасным и хорошо выполняет свою работу.
Увидеть фреймворки в действии, можно на Livecoding.tv, здесь вы найдете Symfony, Yii и Laravel каналы. Связаться и задать вопрос разработчикам можно в чате или по Skype во время стрима.
Автор: Dr. Michael Jurgen Garbade
PHP широко используется в крупных проектах. Facebook, например, использует PHP для сохранения и создания своих внутренних систем. WordPress использует PHP, чтобы оживить свои внутренности, которые в свою очередь приводят в движение более чем 26% сети. На сегодняшний день на PHP работают более 82% веб-сайтов.
В этой статье мы рассмотрим три самых популярных PHP фреймворка: Symfony, Laravel и Yii. Мы рассмотрим и сравним их, чтобы помочь вам решить, какой из них будет наилучшим образом подходить под ваши нужды.
Зачем нужен PHP фреймворк?
Какой смысл использовать фреймворк вместо чистого PHP для разработки приложения? Несколько преимуществ использования фреймворков:
- PHP фреймворк делает разработку быстрее. Например, вам не нужно писать сложные запросы для извлечения данных из базы. Фреймворки включают CRUD операции (Create, Read, Update и Delete).
- Фреймворки позволяют разработчикам легко масштабировать системы.
- Код приложения краткий и с ним легко работать.
- MVC обеспечивает быструю разработку.
- Безопасность веб-приложений выше.
- Минимальное количество кода имеет максимальный эффект.
- Вышеуказанные преимущества являются слишком значительными, чтобы быть проигнорированными. Несмотря на это, чистый PHP может быть использован для создания любого приложения, действующие стандарты требуют разработки инструментов и навыков тайм-менеджмента для удовлетворения рыночного спроса.
Как выбрать PHP фреймворк?
Задайте себе пару вопросов ниже, они помогут вам в выборе:
- Каковы особенности и функциональные возможности фреймворка? (Есть ли в нем то, что мне нужно?)
- Насколько его сложно изучить?
- Насколько высокий уровень масштабирования фреймворка?
- Активно ли развивается и поддерживается?
- Обеспечивается ли основа долгосрочной поддержки (LTS поддержка)?
- Есть ли у фреймворка сильная поддержка сообщества?
Symfony, Laravel, и Yii
Прежде чем погрузится в технические подробности, вот краткий обзор претендентов:
Symfony
Symfony представляет собой набор повторно используемых компонентов PHP, что позволяет разработчикам создавать масштабируемые, высокопроизводительные приложения. Выбрать можно из 30 компонентов, разработчик имеет полную свободу экспериментировать и работать в среде RAD. Symfony API позволяют также легко интегрироваться с приложениями сторонних разработчиков, и он может быть использован с популярными фреймворками, такими как AngularJS.
Многие популярные проекты, в том числе Drupal и phpBB, также использовали Symfony. На самом деле, Laravel, самый популярный PHP фреймворк, это построен на Symfony.
Laravel
Laravel имеет отличное сообщество и опережает всех в списке наиболее популярных фреймворков. (Одиним из ведущих разработчиков Laravel на Livecoding.tv является Sfiskell.)
В мае 2015 года Laravel объявила, что версия 5.1 будет включать долгосрочную поддержку в течении двух лет. Версия 5.2 была представлена в декабре 2015 года. Многие хостинг компании предоставляют поддержку Laravel и предлагают хостинг решения для приложений на Laravel.
Yii
Yii является безопасным, быстрым, высокопроизводительный фреймворком для веб-разработки и разработки приложений. Yii использует менеджер зависимостей для PHP для обработки различных зависимостей и установок (подробнее об этом позже). Yii также является самым быстрым PHP фреймворком.
Еще одна интересная особенность Yii интегрирован с Jquery. Интеграция позволяет front-end разработчикам быстро охватить фреймворк. Подобно Symfony, Yii также использует компоненты, обеспечивающие быструю разработку приложений.
Как их сравнить
Все три фреймворка идеально подходят для создания веб-приложений 2.0, но каждый из них служит разным целям. Давайте посмотрим на их особенности.
Шаблонизаторы
Шаблонизаторы сводят к минимуму усилия разработчиков и обеспечивают лучшую функциональность.
Система шаблонов Symfony Twig
Twig это современный шаблонизатор для PHP. Symfony использует Twig в свою пользу и позволяет разработчикам писать чистый, лаконичный код с возможностью сделать больше, чем на чистом PHP. Например, он принимает следующий подробный код:
<?php echo $var ?> <?php echo htmlspecialchars($var, ENT_QUOTES, ‘UTF-8’) ?>
Twig делает то же самое со следующим кодом:
{{ var }} {{ var|escape }} {{ var|e }} {# shortcut to escape a variable #}
Узайте больше о Twig и его особенностях на официальном сайте.
Система шаблонов Laravel Blade
В отличие от других шаблонных систем, Blade позволяет использовать PHP код в представлениях. Весь код в представлении файлов превращается в чистый PHP во время обработки.
Система шаблонов Yii Default
Yii не использует каких-либо третих систем по умолчанию, но это не означает что ему не хватает поддержки системы шаблонов. Выбор системы шаблонов зависит от команды разработчиков. Symfony использует Twig, поэтому, если вы использовали Symfony в прошлом, вы захотите использовать Twig для вашего следующего проекта на Yii.
Здесь нет явного победителя. Все три фреймворка используют шаблонны для улучшения front-end разработки и технического обслуживания. Небольшое преимущество Yii является то, что фреймворк не имеет заранее определенную шаблонную систему.
Разница фреймворков
Symfony работает на повторно используемых компонентах и обеспечивает лучшую модульность. Symfony также использует модель и контроллер для разработки веб-приложений, который может выглядеть плохо для многих новых разработчиков, но это работает. Кроме того, Symfony является хорошим примером модульного фреймворка. Вы можете использовать 30 компонентов, предоставленных Symfony в проекте по модульному принципу.
Yii это MVC фреймворк. (Symfony действительно обеспечивает поддержку MVC, который обсуждается более подробно в Is Symfony2 MVC framework на сайте blog.sznapka.pl.)
Symfony может быть использован для быстрой разработки и сложных проектов. Несмотря на это, есть мнения о том что фреймворк лучше использовать для сложных проектов. Yii также использует компоненты, но не в качестве модульных как Symfony.
Если вы ищете модульный фреймворк, обратитесь к Symfony.
Загрузка
Эти три фреймворка имеют несколько процедур установки. Если вы используете composer для манипулирования пакетами, вы будете рады узнать, что все механизмы могут быть установлены с помощью composer.
Для Symfony, роль composer является более важной. Идею компонента обработки лучше всего реализовать с помощью менеджера зависимостей Composer PHP.
Существуют и другие способы установки соответствующих фреймворков. Например, вы можете установить фреймворк, используя простой метод архивирования.
После установки Yii предоставляет вам веб-приложение и шаблон для работы. Symfony2 также предоставляет демо-приложение, чтобы начать работу.
Laravel также легко установить с помощью composer create-project или с помощью Laravel Installer. Детальное руководство по установке Laravel.
Быстрая разработка
С точки зрения компании или клиента, очень важно быстро получить приложение на рынке для удовлетворения потребительского спроса. Symfony выделяется за то, что за ним прочная основа с сильным сообществом. Laravel быстро растет, но он еще не может считаться основным PHP фреймворком. С другой стороны, если у вас нет каких-либо знаний о PHP фреймворках и вы хотите начать работу как можно быстрее, рассмотрите Laravel. Laravel простой в плане обучения, вы найдете много учебников в интернете, которые помогут вам начать работу. В свою очередь Yii поднимает производительность на новый уровень.
Эффективность
Производительность любого приложения имеет значение только тогда, когда это в режиме реального времени приложение использует критически важные данные. Как много веб-приложений зависит от высокой производительности? Не так много, но производительность фреймворков может сыграть решающую роль во многих проектах.
Социальные сети являются ярким примером событий в реальном времени и один из наших топ стримеров, jadson, построил мобильную социальную сеть с помощью Yii2. Когда речь заходит о выборе наилучшей основы для создания приложения высокой производительности, Yii выделяется как самый быстрый PHP фреймворк.
Производительность Laravel является весьма дискуссионной темой. Он самый медленный, но имеет ли это значение когда в сети есть масса ресурсов для ускорения производительности, в том числе руководство на GitHub для ускорения Laravel приложений.
Поддержка баз данных
Symfony 2 обеспечивает лучшую поддержку баз данных. Вы можете работать с массивом баз данных, в том числе NoSQL и DynamoDB. Yii и Laravel также полезны, но они поддерживают меньше, чем базы данных Symfony. Поддержка баз данных каждым отдельным фреймворком отображена в таблице.
Сообщество и ресурсы
Залогом продолжительной жизни фреймворка с открытым исходным кодом является сила его сообщества. Все три фреймворка имеют сильные сообщества, хотя Symfony-х немного более зрелым в этом плане. Предсказать динамику развивития сообществ в будущем является сложной задачей.
Laravel документация
Symfony документации (3.0)
Yii документация
Сходства
Мы рассмотрели различия между фреймворками. Теперь давайте посмотрим на их сходства:
- Все три фреймворка являются full-stack PHP фреймворками и предлагают функциональные возможности для создания веб-приложений, от front-end до back-end
- Проекты с открытым исходным кодом и их исходный код можно найти на GitHub
- Фреймворки хорошо документированы и поддерживаются большими сообществами
- Каждый из них поддерживает ORM (Object Relationship Mapping)
- Они являются надежными и безопасными для создания веб-приложений 2.0
Все еще в раздумиях? Может быть, эти пункты помогут вам сузить круг:
Symfony:
- Включает LTS релиз
- Поставляется с массой функций
- В настоящее время является наиболее стабильным
- Имеет большое сообщество с большим количеством учебных ресурсов
Yii:
- Поставляется с поддержкой Ajax
- Отлично подходит для разработки приложений в режиме реального времени
- Является очень расширяемым
- Хорош для создания веб-служб RESTful
- Имеет большое сообщество с большим количеством учебных ресурсов
Laravel:
- Самой популярный фреймворк 2015-2016 годов
- Поддерживает Composer для управления пакетами
- Хорошо делает модульное тестирование
- Предлагает тонны пакетов для расширения функциональности фреймворков
- Имеет большое сообщество с большим количеством учебных ресурсов.
Вывод
Если сравнивать Symfony, Laravel и Yii, все три PHP фреймворка являются отличными вариантами, которые обеспечивают full-stack разработку. Но лично для меня, Laravel является победителем, который превращается в звезду.
Тем не менее, Symfony и Yii тоже отличные варианты. Symfony хорошо разработан и имеет более крупное, зрелое сообщество. Yii является надежным, безопасным и хорошо выполняет свою работу.
Увидеть фреймворки в действии, можно на Livecoding.tv, здесь вы найдете Symfony, Yii и Laravel каналы. Связаться и задать вопрос разработчикам можно в чате или по Skype во время стрима.
Автор: Dr. Michael Jurgen Garbade
Поделиться с друзьями
Fesor
Ух....
Нет, фреймворк имеет в себе решения наиболее стандартных задач, вроде аутентификации, или базовые компоненты для организации структуры. Сложные запросы всеравно придется делать если запросы сложные, а если все просто то и запросы простые.
далеко не все. И как бы… если у вас CRUD имеет смысл вообще отказаться от идеи писать бэкэнд и воспользоваться каким Backend-as-a-service или всякими Firebase-ами. Скорость разработки будет намного выше.
Опять же нет. Для этого у разработчика должно быть в голове представление о том как масштабировать систему в принципе.
Больше чуши богу чуши. Как сделаешь так и будет.
Ничерта подобного. smartui (то есть отсутствие mvc) обеспечивает еще большую скорость разработки, но только стоимость поддержки будет меньше. MVC — это разделение обязанностей. Если у вас html от php отделен это еще не mvc. Ну и web так и работает.
Это называется “сокрытая сложность”. Ну то есть это преимущество несомненно но нужно знать инструмент.
Статья ниочем… как пример довод про Yii:
нет, это фреймворк с очень высокой связанностью. Беря его вы сознательно говорите себе что срок жизни проекта будет не больше жизни фреймворка (текущей версии). То есть Yii дает вам очень высокую скорость разработки но шаг влево шаг в право и вы уже сражаетесь с фреймворком. Не говоря уже о том что "сменить" какой то из компонентов уже не выйдет. И это не недостаток, это трейдоф на который идут разработчики дабы было быстрее.
Symfony — другая крайность. Все явно, все надежно… идеален для больших проектов и по настоящему легко расширять, но требует чуть больше знаний и опыта. Ну и Doctrine не часть симфони потому говорить об ORM не стоит.
Laravel — посерединке. А еще есть целая куча других фреймворков.
SerafimArts
Я бы, как симфонист, поменял симфони и ларку местами. Учитывая 99% ую декларативность симфони шаг влево или шаг вправо влечёт боль и горение. В тоже время в ларке всё императивно, как следствие — можно как угодно изгаляться, сохраняя единообразие и консистентность подходов, при этом иметь возможность подняться до уровня декларативщины и yml и аннотаций в пару тычков. Да и из коробки предоставляется на порядок больше всего.
В общем, симфони — это конструктор "Винтик и Шпунтик" из суровых 90х (вообще не поменялся почти), но только вместо винтиков — резинка от трусов (ну т.е. дефолтный yml), а ларка — лего, причём поставляется он сразу собранным, всё что можно сделать — это разобрать на кусочки, ибо ставить ничего не надо — всё и так есть. Yii — это просто статуэтка, ничего не добавить, не поменять, но когда нужны статуэтки — идеальный вариант без заморочек.
Конечно же это всё моё большое "имхо", но готов поотвечать на вопросы и попробовать чуть поподробнее аргументировать своё мнение.
Fesor
Ну вот давай по правда, симфонист я, а ты ларавельщик) и мы трактуем все исходя из своего личного опыта. У тебя проект где контейнер инджектится и используется напрямую в сервисах, а у меня на ревью проекты на ларавель приходили только те где все было по контроллерам размазано и статика кругом. Согласись, все относительно.
что же я делаю не так что у меня нет этой боли?
проблемы начинаются ровно тогда, когда люди бросаются в крайности. мол "все декларативно" или "все императивно".
ты в симфони можешь "спуститься" чуть ниже до уровня декларативных конфигов на php.
а вот тут соглашусь. Симфони из коробки это весьма примитивный каркас. Особенно в моем случае, когда я из симфони выкидываю вещи вроде форм, твига и тд. По сути полноценно я только доктрину использую но это не часть симфони)
Посмотри spring. Мне как-то понадобилось spring integration заюзать… так я на сутки утанул в XML-ках.
только элоквент выкинуть и на доктрину заменить, потому что те проекты которые здорово и весело пишутся на элоквенте я просто на firebase перевожу.
Ну это так, что бы холивар поддержать)
SerafimArts
Ларавельщик я в душе, а на работе — суровый бородатый симфонист. Так что мы всё трактуем, исходя из того, с какой стороны посмотреть ;)
У симфони контейнера нет возможностей из коробки делать плюшки, вроде инъекций в методы во время вызова, отсюда появляются такие монстры, как "сервис фектори абстрактных фектори", более того — он буквально пропагандирует "сервис локацию", так что… Короче, слишком академичный, как Фаулер завещал, да и предлагаю вспомнить коммены Фабьена на гитхабе по поводу автовайринга ;)
Ну это да, но я специально выделил жирным про консистентность. С другой стороны, имея руки из правильных мест...
Ну что я могу сказать по этому поводу:
Нене, доктрину не надо, эта фигня зачастую доставляет больше проблем, нежели их решает. Поправил одну строчку и отвалился весь проект, потому что знаете ли идентити мап… Вот блейд фтопку, да, твиг поставить и идеал, а доктрина фу-фу.
Я рассказывал случай замечательный про персистер и праймари ключики? Если да, не обессудь, после него я поседел:
Вот есть, значицца, энтити некоторый, есть апи, и есть праймари ключик, который является идентификатором этой энтити в этом самом удалённом апи-сторадже. Ну, допустим:
Создаём мы штук 10 этих энтитей, ставим им права и прочее-прочее, делаем запрос:
Внутри вызова "создания объекта в апи" делается запрос и устанавливается
id, если всё ок, иначе ошибки, кровь, кишки и всё плохо.Но тут вдруг ошибка на строчке с persist — пишет, мол так и так, какого фига ты фигачишь мне энтити без праймари ключика? Ну ок, первым делом, делаем дамп (точку останова, по вкусу) этой энтити, выводит
42...Ну ты понял, да? Ошибка отсутсвия значения ключика для энтити, у которой есть значение этого ключика.
Проблема в том, что при создании энтити туда фигачатся релейшены этих энтити, ну там группа этого пользователя, например. А во время персиста происходит следующее:
Занавес.
oxidmod
Так и не осознал о чем написано. Но, если не поставить каскад персист, то релейшен не персистится. Думать надо, а не каскад all тудить везде
SerafimArts
Энтити используются в нескольких местах и очевидно что в одном кейсе каскад персист нужен, но в этом из-за него всё рушится.
oxidmod
приведите кейс. не могу придумать
SerafimArts
Когда нужен каскад персист? Ну тот же самый:
oxidmod
кейс когда в одном месте он нужен, а в другом не нужен.
Вот покажите теперь такой кейс когда вам каскадный персист помешает с юзером
Fesor
Потому что это выходит за рамки функционала иньекции зависимостей, называется это дабл диспатч. А почему нет простой возможности взять сервис не по названию а по типу объекта — можешь почитать в ишус трекере симфони.
В Laravel например у тебя есть метод в контейнере для этого, но для этого тебе надо контейнер получить весь.
С другой стороны тебе никто не мешает сделать отдельный компайл пасс который будет это разруливать. Да и честно — можешь привести примеры когда это нужно? В 99% случаев достаточно иньекции в конструктор.
вот не надо, как разработчик сделал так и будет.
в каком месте?
ну не нравится ему магия, я его понимаю… я эту магию добавляю сам)
что бы было не так достаточно прочитать разок документаци.
это ж как надо написать проект что бы он из-за идентити мэп падал....
я помню что там была какая-то лютая наркомания. и мы всей толпой не понимали зачем ты так делаешь. У меня никогда небыло проблем с айдишками которые я сам задавал, например UUID.
SerafimArts
Любой метод любого контроллера
Наверное потому, что доктрина не умеет связывать релейшены, где не участвует праймари ключик ;)
Fesor
наверное если ты почитаешь документацию к доктрине, там говорится "не делать так". И тогда у меня вопрос, зачем ты так делал и почему потом винишь доктрину в том что ты убил кучу времени? Такие связи не особо даже укладываются в обычные взаимоотношения бизнес объектов.
SerafimArts
Оуоуоу, давай ещё раз перечитаем. Я написал, что доктрина не умеет делать релейшены без PK, по-этому и пришлось делать внешний айдишник именно PK для связи энити с другими из этой же внешней системы. И это работало вполне до тех пор, пока...
P.S. А за ссылки спасибо, пойду покурю, вдруг что интересного найдётся. И да, контроллер — это лишь обработчик событий (ну т.е. презентер, передающий данные туда-сюда). Я не вижу совершенно никакой разницы между ним, и, допустим миддлварями. Таким образом можно сказать, что сервис-локатор это вообще норм.
SerafimArts
Нет, по ссылкам совершенно очевидные вещи, ну кроме последней, там микрохоливар. Подытоживая — это не отменяет моего тезиса о том, что контейнер в симфони слишком академичен и им просто не удобно пользоваться.
claygod
Примеры приложений, которые вы видите на baas, можете описать? Т.е. где вы проводите разделительную линию?
Fesor
тут нужно несколько факторов учитывать.
сложность задачи. Например делать сложные выборки в том же firebase весьма проблематично, так же чем сложнее выборки тем сложнее моделировать структуры данных. Скажем в mongodb намного проще работать со сложными структурами данных. Или для сложных агрегаций лучше просто эластику взять.
ситуации, когда у клиента достаточно информации о том, можно записывать или нет. Если информации недостаточно — проще и удобнее будет выставить свой бэкэнд. Из baas мне больше всех нравится firebase
ситуации, когда недостаточно информации но при этом предыдущим пунктам пока соответствует. Например MVP/прототип продукта для более детального анализа. В этом ключе BaaS более чем удобны. Пока правда логика не становится сложной потому это нужно как-то учитывать. Из примеров… например делаем мы какую-то систему и клиенту нужен сырой прототип что бы начать переобучение сотрудников… или просто инвесторам показать что-то интереснее прототипов в инвижене.
Ну то есть вполне может быть такой вариант. Мобильщики очень быстро накидывают прототип приложения, а бэкэндщики спустя пару итераций начинают писать свой бэкэнд и система планомерно переводится на него.
С тем же firebase мы можем поставить за ним свой бэкэнд, и постепенно перекидывать отдельные API колы на наш бэкэнд. таким образом мы можем очень быстро предоставить MVP клиенту, и планомерно переводить все на свой бэкэнд с ростом запросов и возможно нагрузки. Причем у нас из коробки есть логины через фэйсбуки (мелочь но приятно), очень шустрое хранилище, offline-first и тд.
Проекты же где сходу видно что все будет не просто — я тут предпочитаю не рисковать и сразу беру свой бэкэнд. У меня пока Firebase только в порядке эксперемента, скажем с parse ситуация очень быстро выходила из под контроля, а возможность легко вклинивать свой бэкэн в firebase очень подкупает.
claygod
Fesor, спасибо за подробный ответ! С тем, что простой CRUD тут не вызовет проблем, всё ясно. А что скажете по поводу сохранения данных, введённых посетителями, например комментариев?
Fesor
а чем это не просто CRUD?
claygod
Я имею в виду валидацию
Fesor
Ну простенькую валидацию данных мы можем производить силами firebase.
TecHMeaT
Информация интересная, но текст… такое ощущение, что читал перевод в Google Translate
Blumfontein
>> Symfony 2 обеспечивает лучшую поддержку баз данных
Не поддерживает symfony 2 ни одной базы данных.
M-A-XG
>PHP фреймворк делает разработку быстрее.
Не факт. Многие вещи на фреймворке приходится делать через костыли.
>Например, вам не нужно писать сложные запросы для извлечения данных из базы.
Сложные запросы на фреймворке или не напишешь, или они будут ужасно тупить
>Фреймворки включают CRUD операции (Create, Read, Update и Delete).
Боже ты мой. Так сложно самому реализовать CRUD?
Зато знаешь, что нету подводных камней.
И при больших выборках все будет работать.
>Фреймворки позволяют разработчикам легко масштабировать системы.
Каким образом?
>Код приложения краткий и с ним легко работать.
На самописи код тоже краткий…
>MVC обеспечивает быструю разработку.
MVC вообще-то не об этом…
>Безопасность веб-приложений выше.
Не факт. фреймворк только расслабляет разработчика и он не думает о безопасности. У него эти способности атрофируются.
>Минимальное количество кода имеет максимальный эффект.
Ниочем.
>Многие популярные проекты, в том числе Drupal и phpBB, также использовали Symfony.
Не знаю, как phpBB, но Drupal переводили нексколько лет. И он полумертвый.
>Yii является безопасным
Остальные небезопасные?
>Yii также является самым быстрым PHP фреймворком
Самым быстрым из этих…
>Еще одна интересная особенность Yii интегрирован с Jquery.
Как? Фишка для начального уровня. Ничто не мешает мне интегрировать Jquery в 2 чиха в свою самопись.
>Все три фреймворка идеально подходят для создания веб-приложений 2.0, но каждый из них служит разным целям.
Вторая часть предложения противоречит первой.
>Шаблонизаторы
О шаблонизаторах:
http://blog.kpitv.net/article/об-автопреобразовании-спецсимволов-в-html-сущности-15412/
>Шаблонизаторы сводят к минимуму усилия разработчиков
Вообще-то на нативном php шаблоны писасть проще. А шаблонизатор многие вещи не позволяет сделать, или приходится гуглить.
>и обеспечивают лучшую функциональность
Функциональность наоборот обрезана…
>Весь код в представлении файлов превращается в чистый PHP во время обработки.
А разве остальные шаблонизаторы не компилируют свои шаблоны в php?
>Symfony также использует модель и контроллер
А остальные не используют?
>Вы можете использовать 30 компонентов, предоставленных Symfony в проекте по модульному принципу.
У моей самописи тоже есть модули… :)
>Yii также использует компоненты, но не в качестве модульных
Что такое модульный компонент?
>Если вы ищете модульный фреймворк
Люди решают задачи, а не ищут модульные фреймворки.
>Laravel быстро растет, но он еще не может считаться основным PHP фреймворком.
Так он же самый популярный Вы писали…
>В свою очередь Yii поднимает производительность на новый уровень.
Какой ценой?
>Как много веб-приложений зависит от высокой производительности? Не так много
Странное утверждение
Пример о соцсети на Yii мимо утки.
Соцсеть можно реализовать на чем угодно, то почему-то ВК и ФБ даже не на PHP.
>Laravel самый медленный
Я думал Symfony
>руководство для ускорения Laravel приложений
Почему оно сразу не настроено?
Вот она скорость разработки. Чем она аукается.
>Symfony 2 обеспечивает лучшую поддержку баз данных.
По большому счету пофиг.
Разве не достаточно использования PDO?
>full-stack PHP фреймворками
Что это такое. Слышал только о фултек программистах…
>веб-приложений 2.0
Зачем эта маркетингоая мишура?
>
Symfony:
Включает LTS релиз
Так и остальные вклчают…
>Поставляется с массой функций
Остальные тоже…
>Yii
>Поставляется с поддержкой Ajax
В чем именно это проявляется? У остальных нету этой поддержки?
>Отлично подходит для разработки приложений в режиме реального времени
Типа чтобы кодить прямо на проде?
>Является очень расширяемым
Так он же не модульный в отлиии от предыдущего.
>Хорош для создания веб-служб RESTful
Чем именно?
>Имеет большое сообщество с большим количеством учебных ресурсов
Лишний пункт, Вы указали это обо всех…
>Laravel
>Поддерживает Composer для управления пакетами
Вы писали это и об остальных…
>Хорошо делает модульное тестирование
Он сам делает тестирование?
>Предлагает тонны пакетов для расширения функциональности фреймворков
А Yii Вы говорите расширяемы, а Symfony — модульный…
TL;DR версия статьи.
Все фреймворки классные, но моя звезда — Laravel.
В общем, КГ/АМ, какой-то фасеточный бесполезный обзор.
П.С.
Чуть не забыл втулить сюда это:
http://blog.kpitv.net/article/frameworks-1/
П.П.С.
Не указаны версии сравниваемых фреймворков.
Fesor
у вас напомню опыт работы только с Yii. И я чуть выше уже говорил что в пользу скорости разработки на некоторые вещи разработчики забили. Компромисы.
модули != компоненты. У симфони это самодостаточные компоненты, которые можно использовть как вместе так и по отдельности. А в вашей самописи модули будут тянуть друг друга или какое-нибудь "ядро".
я ищу модульный фреймворк что бы иметь возможность эффективно решить задачи, которые имеющиеся модули не решают. То есть если мне чего-то нехватает я могу написать свой модуль или найти готовый. Собственно по этой причине до сих пор не слез с симфони.
писать — проще. Читать — сложнее. Ну и фронтэнд разработчику проще взять вещи вроде twig (jninja, nunjucks) поскольку синтаксис будет им знаком.
то есть не нужно изучать инструменты которые вы используете? Многие вещи которые шаблонизаторы не позволяют делать (или не позволяют делать из коробки скорее) — это скорее благо. Да и расширяются они неплохо. Хотя штуки вроде blade больше похожи на велосипед.
да этот пункт вообще ниочем (ну мол на который вы вопрос задавали)). В laravel модульным тестированием (unit testing) называют интеграционные. А так как сделаешь так и будет)
поправлю автора, симфони не использует термин "модель". Симфони это по сути UI фреймворк (где UI это CLI, HTTP или что угодно другое). Модель, то есть само приложение, это отдано на откуп разработчикам. Они могут организовать модель как захотят. Как анемичный трешачек в духе yii или laravel4 так и что-то адекватное (сервисный слой, доктрина на всю катушку, cqrs/es и т.д.)
M-A-XG
>модули != компоненты
Это уже вопрос терминологии.
Я контроллеры называю компонентами. (из-за того что начинал с Битрикса).
>А в вашей самописи модули будут тянуть друг друга или какое-нибудь «ядро».
Модуль у меня — это любой часто (повторно) используемый функционал.
Модуль реализируется через автозагрузку и начинается с пространства имен modules
Есть модули базового уровня, есть прикладного. Прикладные вызывают базовые.
Модули у меня выполняют роль моделей, но они не такие, как в понимании фреймворков.
>писать — проще. Читать — сложнее.
Используйте short_open_tag — все отлично. :)
>то есть не нужно изучать инструменты которые вы используете
Я не хочу изучать мусор.
Я решаю задачи минимально необходимыми средствами, не люблю оверхеда, мне не нужно лишнее звено, с багами которого нужно бороться.
Прежде всего речь о шаблонизаторе Smarty.
>Многие вещи которые шаблонизаторы не позволяют делать (или не позволяют делать из коробки скорее) — это скорее благо.
Мне достаточно цикла, условия, перехода к следующей итерации цикла, преобразования спецсимволов, иногда использовать локальную переменную.
А также возможность вызвать и отрендерить в шаблоне подконтроллер/подшаблон.
Fesor
вся соль терминов и названий в том что бы вас понимали. А если вас не понимают, то имеет смысл задуматься о том что бы разобраться с терминологией все же.
он же зависит от чего-то "вашего" помимо себя.
серьезно, попробуйте twig и посидите на нем месяцок и потом вгляните на шаблоны на php.
вы с такими мыслями рискуете застрять на одном месте, потому что "циклов условий и переходов к следующей итерации цикла" вам надолго не хватит. Если вам комфортно — не вопрос. Но других не агитируйте.
наследование шаблонов, расширение их, вот это по настоящему удобно. Просто на PHP без препроцессинга это реализуется дикими кастылями.
M-A-XG
>вся соль терминов и названий в том что бы вас понимали
Согласен.
В публичных дискуссиях о фреймворках я придерживаюсь терминологии фреймворков.
Относительно модуль/компонент.
Я сторонник меньшего количества сущностей.
В чем смысл наличия обоих?
В чем смысл виджетов?
>он же зависит от чего-то «вашего» помимо себя.
Я ж написал:
>Прикладные вызывают базовые.
Не дублировать же функционал.
Модули очень модульные. :)
>попробуйте twig и вгляните на шаблоны на php
Что там такого меня должно подкупить. Документацию/хелпы о нем конечно читал, но уже не помню :)
>наследование шаблонов, расширение их, вот это по настоящему удобно.
Наследование реализуется легко.
Обычным ООП наследованием класса конкретного шаблона :)
Расширение тоже есть. Но инициатором расширения обычно является контроллер. Хотя можно расширить и не только из контроллера. Расширение реализуется без наследования. Используется не часто.
:)
В twig наследование используют для того, чтобы расширить? :)
Шаблонизатор — это по сути другой язык.
Зачем мне учить другой язык?
Fesor
компоненты — самодостаточны. Модули — нет, это модули "для компонента" так сказать. В симфони в качестве модулей выступают бандлы, как удобный способ быстро подключить какую-то функциональность в контейнер зависимостей. Но можно и без бандлов жить, просто не так удобно.
И вы пользуетесь своей терминологией, так как судя по нашим предыдущим дискуссиями не особо сведущи в "общей".
А вы просто попробуйте. Пересильте себя. Это такая штука… преимущества которой хорошо видно в ретроспективе.
"класс" шаблона это уже попахивает. И композиция всегда лучше наследования.
Что бы удешивить поддержку! Что бы другому разработчику не пришлось тратить время на изучение вашей причудливой системы шаблонов с наследованием через классы. Уж поверьте, найти фронтэнд разработчика знакомого с nunjucks например (синтаксис которого 1 в 1 twig, как никак общие предки) мне будет значительно проще.
Словом… ваши доводы "работают" только с одним допущением: маленькие проекты которые делаются целиком и полностью в одиночку. У меня чуть другие проекты, и ваши подходы приведут к огромным издержкам на разработку и поддержку.
M-A-XG
>компоненты — самодостаточны
Модули низкого уровня тоже :)
>«класс» шаблона это уже попахивает
Только для автолоада.
Я их ни разу не наследовал.
Я тоже наследование не люблю.
Параллельно могут работать обычные файловые шаблоны.
>Словом… ваши доводы «работают» только с одним допущением: маленькие проекты которые делаются целиком и полностью в одиночку.
Да, прежде всего я говорю о своей самописи. :)
Но на всех моих работах мне приходилось или делать логику шаблона, или делать шаблон полностью. Так что это нагружает программиста необходимостью знать еще один «язык».
oxidmod
язык — это лишь инструмент. Хороший мастер выбирает подходящий под задачу инструмент. Да, консерву можно открыть молотком, но зачем если есть консервный нож?
VolCh
Это же надо изучать консервный нож.
M-A-XG
Тупая аналогия.
Язык, как Вы сказали, это лишь инструмент.
Любым языком можно сделать почти что угодно.
Вы просто не осилили php.
П.С.
Сомневаюсь в адекватности минусующих.
Скорее всего у них уровень школьников. :)
VolCh
Почти любым языком можно сделать почти что угодно. Но некоторые вещи делать на некоторых языках означает неэффективно использовать как вычислительные, так и человеческие ресурсы. Вот, например, в вашей «самописи» наверняка используются средства SQL для объединения данных из нескольких таблиц. Это можно сделать средствами PHP? Можно. Стоит это делать? В большинстве случаев — нет. Но вас же не удручает ноебходимость знать ещё один язык — SQL (а для чего-то более менее универсального — кучу его диалектов). Так и с шаблонизаторами. Можно делать рендеринг HTML, XML, JSON,… на голом PHP, а можно использовать специально предназначенные для этого средства.
M-A-XG
>Вот, например, в вашей «самописи» наверняка используются средства SQL для объединения данных из нескольких таблиц.
Расскажите подробнее, что Вы имеете в виду. :)
Для объединения SQL в любом случае нужно использовать SQL.
И я в своей самописи не пишу запросы вручную.
За меня это делает API.
Я знаю SQL не для объединения таблиц, а для выборки данных.
В теоремах есть такое понятие «необходимо и достаточно».
Все. Зачем мне тянуть кучу зависимостей от разного мусора.
Я делал сервис, где пользователи для своих сайтов могли менять шаблоны в Smarty.
Шаблоны шаблонов делал сам.
Но это ужасно неудобно было и плюс небезопасно: пользователь мог выполнять php-код.
>рендеринг JSON
Я когда-то тоже не знал о json_encode() :)
>использовать специально предназначенные для этого средства
А без этих средств вы как без рук. :)
А с этими средствами — как со связанными ногами.
Fesor
то есть вы вместо "чужого мусора" написали свой квери билдер. Круто. Внутри то он SQL как получает? Магия и единороги?
Что бы не писать свой мусор.
вы видимо еще не знаете о таких чудных вещах как отдельные компоненты для сериализации вроде symfony/serializer, которые хэндлят многое из того что json_encode не умеет. В частности — вы пробовали \DateTime объекты в большой коллекции хэндлить правильно тупо через json_encode?
M-A-XG
>то есть вы вместо «чужого мусора» написали свой квери билдер.
Я сделал то, что мне нужно.
Все пресутствующего сейчас — УГ.
>Внутри то он SQL как получает
Это у предыдущего оратора спросите, что он получает для объединения 2 таблиц.
>Что бы не писать свой мусор.
Написать свое — во многих случаях выходит дешевле стоимость владения.
И который раз пишу, о дополнительных звеньях багов и тормозов.
>вы пробовали \DateTime объекты в большой коллекции хэндлить правильно тупо через json_encode?
Коллекции это массивы?
В чем проблема? Почему именно с большой коллекцией, а не с маленькой?
VolCh
JOIN, вместо того чтобы загрузить
Вы же говорите «самопись» значит пишите вы. Вот за меня обычно запросы пишет сообщество Doctrine :)
А я когда-то не знал ещё и о Twig, а теперь знаю и активно использую, если нужен динамический HTML-контент на стороне сервера.
Как раз с руками. С голыми, без инструментов и даже перчаток. Работать, конечно, можно, но неэффективно получается, особенно если писать не write-once-read-never код, да ещё чтобы безопасный был.
M-A-XG
JOIN вместо 2 запросов?
Я Вас разочарую.
Тот же Yii 1.1 (это то, что я знаю, тут мелькала инфа, что и 2) хоть и делает 2 запроса, но джойнит :)
Иногда лучше сделать JOIN, иногда 2 запроса.
Также без JOIN не обойтись, если фильтрация/сортировка/группировка сразу по двум таблицам.
VolCh
Я про то, что вы делаете джойн по двум таблицам иногда, вместо того, чтобы делать фильтрацию/сортировку/группировку на стороне PHP? И явно не потому, что не осилили PHP, и необходимость учить другой язык не остановила.
M-A-XG
Вы описываете какие-то извращения.
Читайте выше, там все написано.
VolCh
Для меня использовать нативные шаблоны добровольно почти такое же извращение как использовать реляционные операции на стороне приложения, а не реляционной СУБД. Под каждую задачу — свой инструмент. По крайней мере если задача не одноразовая, которая будет постоянно работать и которую надо будет постоянно поддерживать.
Fesor
вопрос продуктивности.
я сомневаюсь в вашем опыте.
M-A-XG
А в опыте автора статьи? :)
CodeKeeper
О, господин толстый тролль все никак не угомонится? Как же так. Тем не менее мы все в предвкушении ссылки на гитхаб, твоего идеального(не перегруженного) фреймверка.
M-A-XG
Почему толстый?
Вы не согласны с критикой статьи?
Если не согласны, то мне больше нечего Вам сказать.
Это все равно, что метать бисер перед свиньями.
CodeKeeper
Так перед тобой никто бисер и не мечет) Так что ждем ссылку на гитхаб :)
M-A-XG
Это ты тролль.
Бисер приходится метать мне.
CodeKeeper
Точно я? Т.е. это я лезу на все популярные IT ресурсы по PHP(Включая говнокодру), во все чаты посвященные фреймверка на PHP и задвигаю свою гнилую статью, которая написана в провокационном варианте(собственно как и весь контент на сайте)?
Нет, это не так. Так что бисер тут перед тобой метают.
Fesor
Ваша критика не конструктивна по большей части.
вы мне другое скажите. Вот у вас нет опыта работы над продуктами, нет опыта работы в больших командах, нет опыта рекрутинга кадров и управления командой. Нет опыта работы с проектами больше чем на пару человеколет. Но при этом вы уже который раз пытаетесь "толкать истину". Я ведь правильно понимаю, ибо если я не прав — расскажите. Ибо пока я не вижу объективных причин "прислушиваться" к вашим "мыслям".
То есть выглядит это все как пустой треп и тролинг.
M-A-XG
>Ваша критика не конструктивна по большей части.
Не я один сказал, что статья ниочем.
>нет опыта работы в больших командах
Большая команда — это сколько?
>Нет опыта работы с проектами больше чем на пару человеколет.
Это что такое?
К мальчику, который говорил, что король голый, тоже не прислушивались.
Нужно мозгами думать, а не авторитетов себе искать.
michael_vostrikov
Да вы и сказку-то толком не знаете.
M-A-XG
http://www.stihi.ru/2008/09/18/679
С вами еще хуже.
Простые люди-то прозрели.
А король и слуги продолжали что-то из себя корчить, но поняли, что вляпались в лужу.
А вы хуже короля и слуг.
Вы слепы. :)
Вот такая суть общественного мнения и отстутствия собственного.
michael_vostrikov
Во-первых, это не сказка Андерсена, а стихи по мотивам. Во-вторых, там в 16 части есть строка «Все очнулись сразу, зашептав...», и в следующей «А король… он понял – люди правы», так что там нет ни слова о том, что к мальчику не прислушивались.
Ну и в-третьих. Фреймворки это код. Покажите свой код, и что вы на нем сделали, тогда можно будет рассуждать о правильности подходов. Не хотите показывать — идите рассуждать обратно в свой бложик.
M-A-XG
Какая разница, сказка или стихи.
Я ж писал выше, что они-то прислушались.
Но вы-то слепы.
Суть в том, что вы очевидные вещи предпочитаете не замечать, ибо не имеете собственного мнения, а пляшете под авторитетов, которые формируют общественное мнение.
michael_vostrikov
Почему это вы решили, что все, у кого мнение отличается от вашего, его не имеют? И почему вы решили, что те, кто использует фреймворки, никогда раньше не писали самописные приложения?
M-A-XG
Перечитайте:
https://habrahabr.ru/post/305626/#comment_9699496
michael_vostrikov
Там нет ответов на вопросы, которые я задал. Я не спрашивал, что вы думаете про фреймворки.
M-A-XG
А я там писал не то, что я думаю о фреймворках, а о статье…
Повторю:
>Вы не согласны с критикой статьи?
>Если не согласны, то мне больше нечего Вам сказать.
>Это все равно, что метать бисер перед свиньями.
Fesor
человек 10+ хотя бы. И не джуны с вордпрессами и битриксами. И не сайтики клепать.
1 человекогод — это год работы одного человека. 10 человеколет — 1 год работы 10-ти человек или 10 лет работы одного человека.
Вообще-то к нему не нужно было прислушиваться, все это и так видели но боялись за свои жизни (король как никак, вдруг решит казнить всех кто засмеется). Мальчик же еще не осозновал последствий своих действий. То есть люди в сказке не заблуждались а просто боялись сказать. С заблуждениями и прозрениями все намного интереснее.
Пару недель назад довелось мне собеседовать человека, который даже засветился на какой-то конфе локального характера с докладиком. Основным тезисом этого доклада, если упростить, было "говно ваш ООП, сложно, солиды не нужны, процедуры и глобальное состояние спасет мир". Об этом видео я узнал только через сутки и потому могу говорить не предвзято. У человека просто небыло ни опыта ни понимания того о чем он говорил. Он не понимал ни зачем нужна инкапсуляция, ни базовых идей вроде разделения ответственности. Причем если не касаться ООП а оставаться в рамках каких-то более простых концепций — все хорошо. Как только те же вещи рассматриваются уже с применением объектов — все, приехали, начинаем нести чушь.
Если не понятна моя мысль, приведу другой пример крайностей. Например в интернете регулярно публикуются видео религиозного характера на тему "НАСА лжет, земля плоская!". Есть тысячи видео с чуваками, которые пытаются разоблочить "массонско-еврейсикй заговор рептилойдов" и свято в эту чушь верят.
Или другую крайность взять. Креоцеонисты. Мол "булшит ваша эволюция, мой дедушка небыл обезъяной!". Есть целая толпа фанатиков, которым плевать на научные доводы — по их версии миру всего 5 тысяч лет (ибо если бы это было не так ветхий завет был бы больше), а все что нужно знать записано в библии.
То есть подытожу. Ваша "вера" в то что фреймворки это булшит не дает вам по другому смотреть на вещи. Что если это вы ошибаетесь? Что если вы чего-то не знаете? Как это проверить?
Вообще есть неплохой доклад на тему доверия к мыслям других людей.
M-A-XG
>человек 10+ хотя бы
Общее количество человек у нас где-то 20, может больше.
А у Вас сколько?
Но не все в одном продукте.
>Нет опыта работы с проектами больше чем на пару человеколет.
Та здрасьте.
>все это и так видели но боялись за свои жизни
Они боялись показаться дураками, идти против общественного мнения.
>говно ваш ООП
Я об этом статью напишу. :)
Есть в ООП нормальные моменты, а есть и способствующие лапше/трудному пониманию кода.
>Ваша «вера» в то что фреймворки это булшит не дает вам по другому смотреть на вещи.
У меня нету такой веры. Я аргументировал, чем они меня не устраивают (по ссылке в корневом комменте).
Не хочу об этом опять тут спорить.
Я лишь хотел сказать, что статья без практической пользы. Пару адекватных людей это тоже заметили.
Fesor
Это какие например?) Детали реализации объектой модели конкретного языка? Попишите на smalltalk например. Ну или Ruby/Javascript.
M-A-XG
http://blog.kpitv.net/article/ооп-может-способствовать-лапше-трудному-пониманию-кода-15417/
Fesor
у вашего "чудного" недоблога ограничение на длину комментариев. Потому...
это называется "инкапсуляцией". И это то самое ради чего ООП придумывался, скрыть от вас детали и оставить только сообщения между объектами. Если вас парит вопрос "а как там свойства меняются в другом объекте" то видимо вы что-то делаете не так.
Что значит "не явно"? Это аргуенты вызовов методов, что тут не явного? Все очень даже явно. И называйте это "сообщениями".
это как-то намекает на то что у вас отвратительно спроектирована система. Все должно быть явно и понятно с первого прочтения.
Вообще-то использование геттеров/сеттеров является нарушением инкапсуляции. "Крутые" чуваки не юзают геттеры и сеттеры. С другой стороны для тупых "структур данных" это удобно ибо PHP не позволяет по другому добавлять проверку прекондишенов при установке значений (волшебный __set не о том).
Инкапсуляция
Опять же капитанство. Если у вас много мест изменяющих одни и те же свойства, возможно вы нарушили замечательный принцип DRY
что это значит, все и так же явно. Вы о том что мол "не используйте глобальные переменные/статическое состояние"? Ну так это справедливо для всего.
в процедурном стиле злоупотребление одно — глобальное состояние. ООП предоставляет нам способ изолировать состояние. И это важно.
Чушь, нужно выносить тогда когда вы хотите что-то изолировать. А вы по хорошему хотите изолировать ВСЕ. Вам бы почитать какой CISP или composing computer programs, про функциональные абстракции и т.д.
Итого: вы не знаете ООП и учите чему-то людей.
SerafimArts
Там не ограничение по размеру, там ошибка на 216ой строке в
/home/www/m-a-x/blog/system/ajax/comments.php.@M-A-XG, пропиши CSubscribeComments в автолоад, а твой Yii (на котором и написан этот бложек) его не может найти =) По-этому и комменты не работают.
michael_vostrikov
Не думаю, что это Yii, разные точки входа и кривая разметка, скорее всего что-то самописное в стиле битрикса.
Вот тебе и самописные системы и отсутствие тестов…
CodeKeeper
Если кто еще не понял, то господин жирный тролль(M-A-XG) специально пишет провокационные статьи в своем блоге чтобы таким образом его раскручивать.
franzose
Это ж не баг, а фича.
M-A-XG
Там было ограничение на длину.
Выставил в 2 раза больше.
А эта ошибка из-за того, что Вы захотели подписаться на комменты, и такого класса на сайте нету. :)
Спасибо за репорт :)
M-A-XG
>это называется «инкапсуляцией»
Я не против инкапсуляции чужого кода, когда есть публичное API.
Но когда я не понимаю, как работает класс, с внутренностями которого приходится работать, это не гуд.
Эта инкапсуляцию основана на «глобальных» свойствах класса.
Скрыли не только от посторонних глаз, но и от своих.
>Что значит «не явно»? Это аргуенты вызовов методов, что тут не явного?
Когда нету передачи аргументов и возвратов. А все делается «инкапсулировано» через свойства класса.
>это как-то намекает на то что у вас отвратительно спроектирована система.
Я говорю не о своей системе. Поэтому и говорю, что ООП может способствовать непониманию.
> «Крутые» чуваки не юзают геттеры и сеттеры.
Они свойства устанавливают/вызывают напрямую. И приватные?
>Опять же капитанство. Если у вас много мест изменяющих одни и те же свойства, возможно вы нарушили замечательный принцип DRY
У меня нет. Просто само ООП не делает код лучше, это не панацея. Говнокож возможен везде. В случае с ООП говнокод более трудно понимаем.
>что это значит, все и так же явно. Вы о том что мол «не используйте глобальные переменные/статическое состояние»?
Это ваша инкапсуляция.
>в процедурном стиле злоупотребление одно — глобальное состояние
Ну да, любую функцию можем вызвать в любом месте.
То же самое со статические методами.
И Вы не ответили о чрезмерном использовании ООП.
>Чушь, нужно выносить тогда когда вы хотите что-то изолировать. А вы по хорошему хотите изолировать ВСЕ.
Я ж писал о допустимости разбития большой ф-и на меньшие. Но главное не переусердствовать.
>Итого: вы не знаете ООП и учите чему-то людей.
Я ничему не учу.
Это наблюдения, что само по себе ООП — это не серебрянная пуля, как это преподносится. Везде нужны в первую очередь мозги.
П.С.
Добавил Ваш коммент :)
MetaDone
Все ваши рассуждения похожи на ситуацию
«Я не могу вилкой есть суп -> вилки плохой инструмент -> столовые приборы не нужны -> буду есть руками»
Ну а потом руки конечно привыкнут к постоянным термическим ожогам, но это не повод безумно бегать и агитировать всех следовать вашему примеру с сомнительной аргументацией «совсем не горячо»,«так удобнее», «так делали наши предки»
M-A-XG
Где я говорил, что ООП не стоит использовать?
aktuba
>Не факт. Многие вещи на фреймворке приходится делать через костыли.
Например? Если можно — 2 кода для решения одной задачи на https://gist.github.com — один на любом фреймворке, второй на самописе.
>Сложные запросы на фреймворке или не напишешь, или они будут ужасно тупить
Серьезно?)))) Примеры дадите или снова пустозвон?
>>Фреймворки позволяют разработчикам легко масштабировать системы.
>Каким образом?
Ну хотя-бы мастер-слейв… Ах, да — вы-же заявляли что 2 базы для одного проекта никогда не нужны)). Боюсь даже представить, что с вами произойдет, если придется использовать 3-4 разных «базы» (ну пусть это будут mysql+mongodb+oracle) в одном проекте. А если их надо разделить на мастер-слейв…
>Функциональность наоборот обрезана…
Т.е. ваша замочись имеет бОльшую функциональность, чем большинство популярных фреймворков? Ок, тогда скажите plz, сколько по времени займет у вас на вашей самописи замена бд c mysql на mongodb. Дня 2-3?
>Разве не достаточно использования PDO?
Нет.
>Модуль реализируется через автозагрузку и начинается с пространства имен modules
Так у вас модуль == класс в пространстве имен modules? о_О
>Для объединения SQL в любом случае нужно использовать SQL.
Нет.
>Я когда-то тоже не знал о json_encode
Вы и сейчас мало о нем знаете))).
>Также без JOIN не обойтись, если фильтрация/сортировка/группировка сразу по двум таблицам.
Снова ошибаетесь.
>Вы не согласны с критикой статьи?
А где почитать критику статьи? Пока вижу бред наркомана.
>Вы просто не осилили php.
Ух ты… Серьезно?)) Судя по вашей ссылке и комментариям — вы php знаете очень плохо. Про другие языки/подходы даже спрашивать не буду.
Ну и напоследок — мне не интересно ваше «ядро» (хотя любой фреймворк — это и есть какое-то ядро, значит у вас просто личный фреймворк, против которого вы так яро выступаете постоянно). Если код внутри такой-же, как ваш код на говнокод — лучше вообще никому подобного не видеть. Если лучше — это хорошо, но судя по вашим комментариям, этот код ни для сложнее блога не подойдет. А значит и нет смысла терять на него время.
ababo
Никак не выбирать фреймворк, ибо для новых проектов не стоит выбирать PHP в качестве языка разработки.
Fesor
Зато в качестве платформы для web выбирать php очень даже неплохо.
Lure_of_Chaos
Вы предлагаете… Perl? :)
ababo
Ассемблер, конечно. Ну это если стыдливо отворачиваться от Python/Ruby/JS/Go.
Lure_of_Chaos
Насчет ассемблера не знаю, а вот на сях вполне реально запилить полноценный веб.
Насчет Perl — не так уж и давно жили перловые CGI-скрипты :)
А вообще, мне интересно было, из какого лагеря «Python/Ruby/JS/Go» PHP-хейтер залетел.
И да, Вы не упомянули почему-то Java.
ababo
Как насчёт веб-сервиса на Golang с websocket API в связке с in-browser приложением на Typescript/React? :0)
SerafimArts
Да вы, батенька, хипстер я посмотрю! =)
andrewnester
Вам лично приходилось писать на Go более-менее большой бекенд?
По моему опыту получается огромное полотно кода из-за специфики языка.
Всё же Go не просто простой, он простоватый
ababo
Большие бэкенды не писал, писал маленькие и средние. Впечатления в целом положительные. Да, порой не хватает выразительности, но я бы не стал переоценивать остроту этой проблемы.
VolCh
Ещё как-то могу понять статические языки, сильные, но Ruby и JS… Та же слабая динамическая типизация.
ababo
Да, но последовательность и продуманность на порядок лучше, чем у PHP.
Fesor
в руби же сильная динамическая типизация, нет?
VolCh
Вроде нет, неявно приведение там есть, это в Питоне из динамических мейнстримов сильная.
alxalx
Вы не правы, в руби именно сильная динамичская типизация.
VolCh
Нет неявного приведения типов? Помнится что-то вроде, если объект в строковом контексте и имеет метод to_str, то он неявно вызывается. Или путаю?
alxalx
Не путаете, такое действительно есть. Вот только среди стандартных классов этот метод определен исключительно для String, так что думаю, этого недостаточно, чтобы не считать типизацию строгой. Например, вот такой код выбросит эксепшен:
a = '1'
b = 1
c = a + b
Предполагается, что to_str будет реализован только в тех классах, которые полностью ведут себя как строки.
andrewnester
не расскажите почему не выбирать PHP?
Lure_of_Chaos
Ни на старичка ZF, ни на дядю CI не взглянули даже.
Лично я люблю Kohana, жаль, что этот фреймворк закопали.
SamDark
Причём закопал его же создатель...
Tesla
Моя любовь к кохане постепенно затихала по мере работы с ней, а когда попробовал laravel, так и вовсе одни негативные воспоминания остались. Кстати, с коханы на лару очень легко перейти.
greabock
Из-за фасадов. Которые, кстати, являются злом. После периода адаптации, следует немедленно от них отказаться.
andrewnester
Фасады хотя бы мокаются, ну а так они зло да
SerafimArts
Фасады — это абстракция над сервислокацией. По-мне, намного лучше вызывать
DB::..., нежелиYii::$app->dbили упасихоспадиContainer::getInstance()->get('db'). Принципиальных отличий ну вообще никаких, разве только этими "фасадами" пользоваться удобнее и имена константные, а не тупо строчки.P.S. Никто не мешает даже такое писать
Blumfontein
>> DB::..., Yii::$app->db, Container::getInstance()->get('db')
Да за любой из этих вызовов бить по рукам надо. Правильно $this->db (то, что вы заинжектили в конструктор класса). А Laravel со своими фасадами тем и богомерзкий, что поощряет лапшу статики где надо и где не надо.
SerafimArts
Мы ведь сейчас про L4 разговариваем, да? Просто в L5 такого уже давно нет, кроме роутера (от фасада которого можно избавиться, заменив
Route::...на$router->...) и схемы (миграций, от фасада которых тоже можно избавиться).Так с критикой за поощрение подобного вы немного отстали, примерно на год. Чуть больше уже.
С другой стороны — тут выше были ссылки (https://habrahabr.ru/post/305626/#comment_9700506) на то, что, мол, сервис локатор нужен в контроллерах. Естественно это мнение я не поддерживаю, т.к. у симфонистов просто нет альтернатив.
VolCh
Есть. Инжектить сервисы в конструкторы.
SerafimArts
Тогда надо каждый раз новый инстанс контроллера на каждый запрос. Это прокатит в случае с контроллерами, но не прокатит, когда приложение требует вызова метода 10 раз подряд в рамках одного инстанса, ну например обработчики событий какие-нибудь. И каждый раз в метод надо инжектить разные объекты, те же самые эвенты.
Blumfontein
>> Мы ведь сейчас про L4 разговариваем, да?
Да ладно, вот открываю какой-нибудь Cache и вижу те же самые фасады (https://laravel.com/docs/master/cache). Master ветка
Fesor
да, но вы же можете их не использовать?)
Blumfontein
Я то могу не использовать, но как это донести до тех умников, которые их использовали в проекте до меня? Как будто у вас не было собеседований, на которых на вопрос «Что вы знаете о паттернах программирования?» следует ответ «Ну там, синглтон».
andrewnester
ещё хуже, когда на собседовании спрашивают — «знаете паттерны проектирования?» — «да» — «что такое синглтон?»
и после это не следует вопрос почему он плох
SerafimArts
О чём в доках тоже написано ;)
P.S. Это просто издежки легаси. С другой стороны кеш-драйвер можно вполне получать через сервис локатор, не думаю что понадобится когда-нибудь несколько инстансов.
Blumfontein
А что толку, что там внутри правильный DI? Статический доступ сам по себе создает глобальную зависимость в том месте, где он вызван.
SerafimArts
Точно так же, как и
$container->get('...'). В этом и проблема.Blumfontein
Я говорю о такой ситуации. Типичная инъекция зависимости в класс выглядит как-то так:
```
class Foo
{
function __construct($bar)
{
$this->bar = $bar;
}
function doSomething()
{
$this->bar->doSomething();
}
}
```
Фасады же и прочая богомерзкая статика делает возможным сделать так:
```
class Foo
{
function doSomething()
{
Bar::doSomething();
}
}
```
И если в первом случае мы создали гибко конфигурируемую зависимость, то во втором прибили этот Bar дюбелями в класс. И без разницы, что там внутри у Bar::doSomething(), хоть DI, хоть не DI, сама запись «Bar::doSomething()» — говнокод.
И если мне это понятно, то огромному количеству начинающих разработчиков нет. Вся официальная документация Laravel написана на статике. Т.о. авторы как бы рекомендуют такой стиль написания кода, другими словами говнокодить.
Fesor
$container->get('...')— это сервис локатор. Не используй контейнер напрямую в коде который не должен знать о симфони и все хорошо)rockin
Ну да, ну да
Фрейворк «кончится», а PHP останется. (вагончик тронется, перрон останется).
И куда вы потом со своим проектом? И знанием умершего фреймворка?
Сколько уже было умерших фреймворков? Какие-то и я изучил до корки. И что теперь?! Да ничего.
Запросы к базе — это ппц как сложно
А парсинг через курл… вау…
Короче, вы поняли.
Fesor
Гексагональная архитектура и инверсия зависимости как раз таки для тех проектов, где время жизни приложения сильно больше времени поддержки мажерной версии используемого фреймворка или библиотек.
не, не понял.
rockin
Время жизни приложения? Что это?
Поматросил и бросил?
Сдал и йух с ним?
А вы не думаете о тех, кому придётся разбирать потом ваш говно-фреймоврко-код?! Поднимать умершие пять лет библиотеки и так далее?
Я даже ни разу не кодер, я — сисадмин. Но мне стопицот раз приходилось смотреть, из чего там слеплен тот или иной компонент.
Стыдно, ребята-программисты, очень стыдно.
Вы лепите код, который умирает после окончания «времени жизни приложения».
Fesor
Время от начала разработки до вывода из эксплуатации. То есть это вместе с "допиливанием новых фич" и "суппортом". До тех пор пока проект не закроется физически. Из таких систем видал штуки которые продолжают исправно работать с начала 80-х.
я — думаю, потому мой код не похож на куски баша. И тесты пишу.
что логично, потому что когда приложение умерло (проект закрылся, он уже не нужен, есть что-то другое на замену) код его тоже никому уже не нужен.
Например есть система которой уже 20 лет. Она уже не удовлетворяет потребности пользователей на 2016-ый год. Появилось очень много чего нового, люди хотят совершенно по другому работать. Итог — новая система, а старая выкидывается. Новая прослужит еще лет 10 может и потом снова выкидывается.
И если 20 лет назад написание такой системы и ее поддержка обошлись бы в миллионы долларов, сегодня с говно-фреймворками и говно-библиотеками это стоит на порядки меньше и срок окупаемости сокращается до года-двух.
rockin
Абсолютно адынэсный подход к разработке
Налепили хрен знает что — разбирайтесь.
Работает криво — ваши проблемы.
Зато херак-херак и в продакшн.
Fesor
вы же понимаете что я могу то же самое про админов начать задвигать?
бесполезные чуваки, лишь бы домой сленять пораньше, мониторинг нормально настроить не могут, базу данных настроить что бы реплики были — слишком сложно пусть "кодеры" делают. Деплойменты наладить — не, кодеры сами справятся. Обновить либки — зачем? и так сойдет. Подумаешь что 100 серваков уже с аутдейтед пакетами.
вы хотите об этом поговорить? Если у вас с вашими разработчиками проблемы — не проэцируйте эти проблемы на всех.
Не херак-херак а "аджайл!"
rockin
Я конкретно про адинце, а не каких-то там разработчиков.
Как часто они отзывают обновления? Да очень часто. А в чём трабл поменять алгоритм исчислений под новые веяния нашей налоговой системы — да ни в чём. Так они регулярно допускают детские ошибки, т.е. работают по принципу как раз «херак-херак и в продакшн».
К чему это я всё. Да любой любитель фреймворков работает по принципу адинцешников. Херак-херак, да побыстрее. Сдать и забыть. Да и пофигу на всех тех, кто потом будет разбирать.
SamDark
Печально, что у вас всё так плохо получилось с разработчиками...
Fesor
вы про битрикс что-ли? причем тут фреймворки и 1-с?
Fesor
я тоже ни разу не кодер, я разработчик. Код — это где-то 30% от моего времени.
Fesor
совсем забыл, есть же еще микросервисы. Вот тут можно разгуляться. Тут у нас одна система может состоять из десятков и сотен приложений, у каждого из которых будет свое "время жизни". То есть какие-то микросервисы мы будем выкидывать уже через пару месяцев, а какие-то могут продержаться по 10 лет например. И поскольку они маленькие — нам удобно их менять.
SamDark
Статья, конечно, шлак полнейший, но кое-что нельзя не откомментить...
Из рассматриваемых.
В табличке ошибки… У Yii отсутствуют Cubrid, Redis, MSSQL, ElasticSearch, Sphinx. Не знаю, что такое Microsoft BI. В Symfony зачем-то запихнули "NoSQL" :)
Я бы не сказал, что PHP в принципе для этого отлично подходит… разрабатывать, конечно, можно, но накладные расходы приличные, если не делать event loop по типу ReactPHP.
В штатах. Опросы на хабре в 2016 показывали первенство Yii и быстрый рост Laravel.
Andchir
MongoDB, CouchDB — NoSQL. Имеете ввиду, что не надо было отдельным пунктом?
Fesor
это все заслуга Doctrine а не Symfony, и ODM из коробки нет. Ну и доктрину можно быстро и в ларавель вставить.
greabock
хватит везде вставлять доктрин )
VolCh
На фреймворк к которому просто Доктрину не подключить, я даже смотреть не буду. Нет у неё конкурентов в мире PHP если нужно разделять логику хранения и бизнес-логику.
Fesor
ну не люблю я active record, ограничивает меня такая реализация. Я доменные объекты хочу а не тупые структурки.
andrewnester
Для Laravel есть AnalogueORM кстати) ну и только для лары
Fesor
есть конечно, а еше есть другие реализации data mapper. Но они не конкуренты Doctrine, слишком цели разнятся. Цель доктрины — предоставить надежный инструмент для быстрой разработки, а цель AnalogueORM — предоставить data mapper и только его. То есть алгоритм простой. Пишем на Doctrine а когда доктрина становится узким местом (до этого доживает не так много проектов) — уже пилим на более простом дата мэппере.
Andchir
Как я понял, это возможно через дополнительный компонент, которого нет «из коробки». Конечно, можно по-быстрому вставить Доктрин, но у таких компонентов есть дополнительные удобные возможности.
SerafimArts
Т.е. по вашей логике, т.к. для Laravel тоже есть мост (bridge) на доктрину с полной поддержкой всего функционала, то Laravel тоже тесно интегрирован с доктриной и можно рассматривать её как встроенный ОРМ? А как же Propel? Там тоже есть мост и на Laravel и на Symfony.
VolCh
Propel тоже тесно интегрирован с Symfony. Хотя по сути в обоих случаях там этой интеграции не особо и много, основной (по объёму) код моста — интеграция в CLI, девтулсы, кодогенерацию, а для собственно рабочего кода — поместить библиотеку в контейнер.
Andchir
В Symfony этот мост идет «из коробки», если в Laravel тоже так, то вполне можно причислять функционал Doctrine и Propel к функционалу Laravel, т.к. это его часть. Но, конечно, было бы более корректно, если бы автор упоминал Doctrine когда перечисляет поддерживаемые базы данных.
SerafimArts
del.
VolCh
Я вот примерно то же хотел написать, но заглянул на symfony.com и понял, что пропустил момент, когда Symfony Standard Edition стала просто Symfony.
SerafimArts
Да не, я просто открыл вендоры, не увидел там
doctrine/doctrine-bundleи отписался, мол нифига не так.Но внимательно разглядев композер — там есть замечательная строчка в секции
"autoload"на доктриновский бридж, прямо внутриsymfony/symfonyпакета. Так что подумал, что моё утверждение по поводу независимости — довольно голословно, по-этому и удалил коммент.SamDark
Ну, тут либо перечислять, либо обобщать. Так можно было и к Yii приписать noSQL и ко всем RDBMS.
rpsv
На вашем месте я бы в статью более практические примеры сравнения вставил: ORM как с ней работать, архитектуру рассмотрел (порядок работы приложения), и др. Не просто текст, а что-нибудь материальное.
Также можно добавить младших братьев всех этих фреймворков (Silex, Lumen ну и Slim — хотя он нечейный брат). Т.к. иногда достаточно обойтись «малой кровью», да и для некоторых приложений ставить большой фреймворк накладно (вернее не имеет смысла).
А вообще было бы неплохо Вам проанализировать все что написано в комментариях, переработать свою статью и запостить. Тогда я думаю у статьи будет положительная карма, да и полезность резко возрастет.
Enapiuz
Абсолютно все описанные преимущества Laravel можно смело писать в преимущества Symfony. Выходит, что Symfony лучший фреймворк в мире!
dbagaev
Статью можно было бы свести к этой строке и не выписывать кучу никак не связанных «преимуществ», из которых нельзя сделать никаких объективных выводов.
Вы когда будете в следующий раз писать сравнение, то сделайте табличку со свойствами, с плюсами и минусами. А потом можно каждый плюс-минус или свойство отдельно рассмотреть, сравнить. А то реально все свалено в кучу и ничего не понять.