В сфере работаю более 15 лет
Контакты

Достижения

Все достижения (17)

Наибольший вклад в теги

Все теги (98)

Лучшие ответы пользователя

Все ответы (138)
  • Отличая Symfony 2 и Yii?

    SowingSadness
    @SowingSadness Автор вопроса
    web-разработчик
    Symfony 2 не так плох как я о нём думал.
    Просто везде не пишут как правильно его использовать.
    Те кто говорят, что он сложный, но лучше, тоже не представляют как правильно «готовить» sf2 + doctrina.

    Все Entity остаются лишь Entity без какой либо логики, только getters и setters.
    Вся бизнес-логика оформляется в виде сервисов.
    В контроллерах только проверка параметров и вызов соответствующего сервиса.

    Все остальные претензии по поводу ошибок, событий и Forms к Sf2 остаются.
    Но с подходом Data Mapping сложность написания и поддержки продукта действительно снижается.
    Т.е. тут сыграл роль лишь Data Mapping.

    В Symfony 2 есть большая проблема с тем что не правильно написан DI Container.
    И поэтому весь код практически сводится к использованию глобальных переменных. Сравните:
    $myService = $this->getContainer()->get('myService');
    /* vs */
    global $myService;

    Преимущество у Sf2 тут исключительно в том, что при использовании сервисов мы знаем что там что-то лежит. Не факт что то что нужно, но что-то лежит. От чего легче не становится.

    UPD
    Какой фрэймворк выбрать Yii 2 или Symfony 2?
    Ответ написан
  • Notepad++ для разработки в Python?

    SowingSadness
    @SowingSadness
    web-разработчик
    Советую прекращать использовать уже Notepad++. Проект был хороший, но он устарел. На его место пришёл Sublime Text 3. Он может всё что мог Notepad++ и уже может больше. У него огромная база плагинов и он развивается 7ми мильными шагами. К тому же плагины для него пишутся на Python.
    Ответ написан
  • Для каких задач больше подойдет MySQL а для каких PostgreSQL?

    SowingSadness
    @SowingSadness
    web-разработчик
    PostgreSQL лучше во всех аспектах, в том числе и по скорости ответа.
    Уже нет причин использовать MySQL.

    PostgreSQL можно продавать со своим продуктом. MySQL - нет.
    PostgreSQL умеет массивы, MySQL - нет.
    PostgreSQL умеет json, MySQL - нет.
    PostgreSQL умеет DateTime с временными зонами, MySQL - нет.
    PostgreSQL умеет работать с временными интервалами, MySQL - нет.
    PostgreSQL умеет нормально работать с unicode, MySQL - нет.
    PostgreSQL умеет DISTINCT по выбранным колонкам, MySQL - нет.
    PostgreSQL умеет ограничивать значения индексов по условиям, MySQL - нет.
    PostgreSQL имеет схемы, MySQL - нет.
    PostgreSQL имеет наследование в таблицах, MySQL - нет.
    PostgreSQL есть нормальная оптимизация JOIN, MySQL - нет.
    PostgreSQL умеет материализованные представления, MySQL - нет.
    PostgreSQL умеет PLSQL, MySQL - нет.
    PostgreSQL умеет Python функции, MySQL - нет.
    PostgreSQL умеет ключи из внешних источников, MySQL - нет.
    PostgreSQL умеет нормальные(вложенные) транзакции, MySQL - нет.
    MySQL есть проблемы с установкой и удалением своих сервисов под Windows, PostgreSQL - нет.
    ̶P̶o̶s̶t̶g̶r̶e̶S̶Q̶L̶ ̶у̶м̶е̶е̶т ̶а̶с̶и̶н̶х̶р̶о̶н̶н̶у̶ю р̶е̶п̶л̶и̶к̶а̶ц̶и̶ю̶, ̶M̶y̶S̶Q̶L̶ ̶-̶ ̶н̶е̶т.
    Ответ написан
  • Как правильно спроектировать Laravel приложение с уклоном в enterprise?

    SowingSadness
    @SowingSadness
    web-разработчик
    Сейчас напишу немного высокомерно, но опыт позволяет. Уже почти 20 лет в разработке и около 15 в веб.
    Надо понимать, что почти все кто используют многочисленные Фреймворки не понимают что такое ООП. А уж тем более, что такое SOLID и т.д.
    И поэтому, что бы они не писали, в конце-концов превращается в какашку с костылями.
    Да, потом героически проект переписывается с учётом изменений (или ещё чаще умирает) Но, он по прежнему остаётся абсолютно не расширяемым и не поддерживаемым.

    И вот мы возвращаемся к Фреймворкам.
    Нужно брать тот Фреймворк, который писали с учётом определённых парадигм и принципов. Так как этих вот парадигм, достаточно описанных и изученных не так много (на самом деле их 2.5 штуки), то можно сразу ориентироваться на ООП + MVC(или MVP или MVVM) + SOLID
    Если Фреймворк что-то из этого нарушает, то он по умолчанию не может вам дать возможность написать хорошее, расширяемое приложение. А хороший Фреймворк, даже начинающим программистам должен прививать правильные подходы к разработке. Что-бы хочешь, не хочешь, а hello world уже не превращался в ад.

    Сразу оговорюсь, что я давно "забил" на Фреймворки. Есть один идеальный — это Pyramid. А оцениваю любой продукт по документации. Там сразу видны все огрехи и косяки. Буду писать и параллельно смотреть в доки.

    Larvel
    Первое что я вижу в этом Фреймворке, что большая часть работы каркасных компонентов завязана на статических вызовах. На этом можно уже, даже и остановиться. ООП, по большому счёту тут нет. Суть ООП в использовании объектов. Тут же класс выступает в качестве пространства имён функций.
    Раз нет ООП, то и нет всей теории и принципов связанных с ним.
    А раз под этим Фреймворком не заложено никакой теории, то в 99% случаев можно сказать, что на нём что-то правильно, написать невозможно.

    Если взглянуть глубже, то открывается ещё больше ада:
    ActiveRecord.
    Плох по умолчанию. С ним очень тяжело контроллировать целостность данных. Вам нужно придумать слой абстракции, где вы будете транзакционно записывать все данные вне бизнес логики. Фреймворк вам тут не поможет. Он предложит это делать в экшене (контроллере). И тут вы столкнётесь, что при написании чего-то сложнее чем бложик, вы будете терять целостность. Ибо бизнес логика и работа БД будет в одном методе. Отладка будет усложняться, ошибок плодиться и т.д.
    И не зависит это от программистов. Шаблон сам по себе провоцирует ошибаться.
    Далеко за примерами ходить не нужно, уже треш.

    Чем больше примеров я смотрю, тем больше не понимаю, как все это дело расширять. Как вставлять прозрачно через весь проект свои собственные аспекстные решения. Например RBAC. Или, если нужно, логику работы приложения отделить от БД и когда нужно, подставлять необходимую реализацию.
    Или сделать работу всех экшенов в рамках клиента, но производить авторизацию по пользователю(сотруднику)

    Все это предлагается зашивать прям в контроллерах, с помощью protected или private методов.
    Повеситься. Сложность приложения зашкалит.

    Symfony
    Только при выходе 2 версии я работал с этим чудом. Разработчики писали его под хапйом dependency injection. Мало того, что они взяли не самую хорошую стратегию для реализации всего костяка фреймворка, так ещё и сделали её не правильно.
    Они написали универсальный DI Container и кладут в него все что угодно, используя в качестве идентификатора строчку.
    Строчку, М**Ь ЕЁ! Не интерфейс — строчку!
    И знаете чем это аукнется? А тем, что при разработке своего приложения или очередного бандла, вам будет говорить, что в контейнере лежит что-то не то и вы подохните в конфигурационных настройках. А все потому что, подход: ВСЁ через DIC — строго навязывается.
    Расширение этого чуда, тоже причинит вам массу головной боли. Ведь, зачастую, вы будете работать с классами, которые ждут не интерфейс, а что-то из контейнера с ключём "я_твой_дом_шатал".

    Проблема с внедрением аспектов сквозь весь фреймворк, никуда не пропадает. Но тут по другой причине. Сложность платформенных компонентов зашкаливает. Все пишется с завязкой на конкретную реализацию, но получают все по строчке из DIC.
    Потому что это центральная концепция. Другой нет.

    Но, по правде говоря, слепить что-то годное возможность есть.
    Если взять микро ядро symfony, прикрутить Doctrine, то получится что-то годное.
    Но встаёт вопрос. А зачем вообще symfony, если можно взять doctrine и написать все остальное свое?
    И тут вы окажетесь правы — незачем.

    Ситуация с Symfony в enterprise очень схожа с ситуацией с Django. Повидал уже с десяток проектов, где последнюю брали для больших приложений. В итоге от Django оставались рожки да ножки. Всю её переписывали.
    Спрашивается — и зачем? Просто потратили кучу времени.

    Так что, если нужен суровый enterprise. Что бы писать что-то большое, с возможностью расширения — берите Pyramid и переходите на python.
    Ничего, даже близко с пирамидкой, по возможностью расширения, даже близко не лежало.
    Ответ написан

Лучшие вопросы пользователя

Все вопросы (7)