Начнем с сессии
ASP.NET поддерживает несколько режимов работы с сессией. Самый простой и стандартный режим In-proc: данные сессии хранятся в памяти процесса, в домене приложения. С любой страницы можно обратиться к Session[«key»] и получить или сохранить данные. В PHP можно выделить два стандартных механизма работы с сессией — файлы и memcached. При работе с сессиями проявляется основное отличие ASP.NET и PHP: сохранение состояния. ASP.NET — это приложение, которое работает некоторое длительное количество времени. У этого приложения есть стек, куча, общие статические переменные. Каждый запрос — новый тред внутри общего процесса. Запросы легко могут взаимодействовать через shared memory процесса. PHP наоборот по своей сути ближе к stateless природе HTTP. Каждый реквест — новый короткоживущий процесс. В памяти процесса ничего не остается между запросами, как и самого процесса. Можно, конечно, передавать объекты через shared memory, но так не особо принято. Лучше хранить данные в файлах, БД и памяти с использованием таких инструментов как memcached. Через
session_set_save_handler() можно хранить сессии где угодно.Синтаксис, типизация и переменные
С одной стороны синтаксис си-подобный и не вызывает с непривычки явного замешательства как, например, синтаксис Python или Clojure. C другой стороны в C# я привык, что есть точка и она для всего. В PHP для обращения к членам экземпляра класса используется
-> (стрелка, T_OBJECT_OPERATOR). Для доступа к статическим членам и константам используется :: (двойное двоеточие, Оператор разрешения области видимости). Постоянно путался, но потом привык.Хуже дела обстоят с переменными. Они нетипизированы, их можно не инициализировать, нету никакого стартового объявления.
<?php
//...
$age = 5;
$age = "five";
//..
?>Это вполне валидный код. Как вы могли заметить перед именем используется $, первое время я про него забывал)
В PHP есть несколько необычных вещей. Например, переменные переменных:
<?php
$a = 'hello';
$$a = 'world';
//Теперь в дереве символов PHP определены и содержатся две переменные: $a, содержащая "hello", и $hello, содержащая "world".
?>Сравнение строк, чисел, объектов.
C# изначально имеет строгие политики сравнения и приведения типов. К сожалению, PHP имеет ряд недостатков, которые упрощают жизнь на простых проектах, но приводят к тому, что обычное сравнение очень часто вызывает недоумение. В оф. доке написано так:
$a == $b TRUE if $a is equal to $b after type juggling.Проблема в том, что правила для juggling назубок знают не многие и они могут быть неочевидными.
Коллекции
В .net есть десятки готовых типов и интерфейсов коллекций, в зависимости от поведения, которое нам необходимо, мы выбираем Queue или ConcurrentDictionary, IList или Hashtable. На собеседованиях проскакивают вопросы про типы коллекций, про отличия интерфейсов и так далее.
В PHP есть только ассоциативный массив (набор пар ключ-значение), других коллекций нет.
Из документации:
Этот тип оптимизирован в нескольких направлениях, поэтому вы можете использовать его как собственно массив, список (вектор), хэш-таблицу (являющуюся реализацией карты), словарь, коллекцию, стэк, очередь и, возможно, что-то еще. Так как значением массива может быть другой массив PHP, можно также создавать деревья и многомерные массивы.
UPD от oxidmod: в SPL есть структуры данных.
Многопоточность
Вы привыкли к многопоточности в .net. Редкое собеседование обходится без вопросов про потоки, пул, lock, async-await и т.п. В PHP многопоточности и асинхроности нет*. Буду рад, если вы поделитесь вашим опытом асинхронного PHP (web) в комментах.
* В PHP есть pthreads, в PHP есть такие проекты как ReactPHP. Но если говорить про web-проекты, я не раз слышал мнение, что PHP не предполагает асинхронных операций.
Инструменты
Visual Studio — один из самых весомых аргументов в пользу дотнет. Бесплатная IDE с богатейшим функционалом является хорошим подспорьем в работе. Добавим сюда решарпер и статическую типизацию и получим удобный набор для разработки, навигации по проекту и рефакторингу. Кроме того недавно зарелизили Rider, который в чем-то даже превосходит привычную Visual Studio. Но windows-only .net-мира являлось сильным тормозом для развития платформы и инструментария вокруг. Надеюсь, что .net core станет новым драйвером платформы.
Если говорить про PHP, то основной средой на текущей момент стала PHPStorm от той же Jetbrains. Строгая типизация только проникает в PHP7, и это усложняет проведение рефакторинга и статического поиска ошибок. Различные нововведения в области type-hinting в последующих версиях языка сделают инструментарий мощнее и лучше.
Также необходимо отметить, что PHP изначально разрабатывался для *nix-платформ и большинство инфраструктурных проектов тоже, все это делает использование таких вещей как docker, mysql, nosql более легким и естественным. Кроме того, такие проекты зачастую являются бесплатными, что обеспечивает широкое распространение. Большинству проектов на PHP не нужны windows-решения вовсе.
Книги
Вот тут все плохо у PHP (на русском). Так как язык кардинально меняет подходы, то покупать и читать книги про PHP 5.x — пустая трата времени и денег. По 7 версии на озон сейчас три книги. Я купил себе Котерова и в целом доволен. И жду пятое издание книги по паттернам и подходам в PHP (выход в очередной раз перенесен, теперь на весну 2018). Первую можно сравнить с Троелсоном (по размеру и глубине). Вторую очень хвалят, как выйдет — обязательно ознакомлюсь. Топ моих книг по .net — Альбахари, Рихтер, Цвалина и Эспозито. Возможно стоит в ближайшее время ждать больше фундаментальных книг по PHP7, но прямо сейчас не нашел актуальных книг, сравнимых по глубине с указанными. Буду рад, если подскажите!
Проекты
Дотнет — это фреймворк общего применения. Вы можете на нем писать десктопные приложения, мобильные приложения, сайты, вебапи и т.д. Есть даже такие разработки как Netduino и .NET Micro Framework. PHP все же больше про веб (либо какие-то фоновые задачи на основе той же кодовой базы, что и основной веб-проект).
На самом деле много типов задач реализуют на PHP: парсеры, чатботы и прочее. Но первым контактом с PHP у большинства разработчиков являются веб-проекты.И именно в вебе PHP представлен намного шире, если считать поштучно, то PHP скорее всего останется лидером еще долго. Да и по уникам вряд ли PHP превратится в аутсайдера: огромное количество сайтов на PHP являются известными проектами с большой аудиторией: vk, avito, badoo.
Развитие языка
Здесь, как мне кажется, принципиальная разница. PHP драйвится сообществом. Новые фичи прилетают в виде RFC, их обсуждают, за них голосуют, включают в релизный план и т.д. У дотнет есть владелец — Microsoft. Сейчас они сделали пивот в сторону опенсорса, они всегда слушали сообщество, но решения принимают достаточно авторитарно. Не знаю какой вариант лучше, есть плюсы и там и там. Развитие дотнет последовательнее и предсказуемее. с другой стороны фича может лежать без движения вечно, так как комитет считает, что прямо сейчас она не отвечает потребностям языка.
Мы видим как развивается C# и .Net. Лично я начинал с 1.1 — помню как появились генерики, linq, TPL. Это было круто. Но все как-то укладывалось в общую канву. Первый дотнет изначально смотрел на готовую Java и принятые там подходы. C# не менялся драматично, как мне кажется.
У PHP более извилистый путь (почитать на Хабре). Язык изначально отличался легкостью освоения, максимальной дружелюбностью к некачественному коду. На нем быстро и без специальных знаний можно было сделать достаточно сложный веб-сайт. В веб-разработку потянулось огромное количество людей без каких-то специальных навыков. В этот период стартовали тысячи проектов, которыми мы так или иначе пользуемся и сейчас. Сложно переоценить вклад PHP в развитие веба. Индустрия росла, появились деньги, появились эксперты, назрела необходимость рефакторинга легаси проектов. И стало понятно, что изначальный код невозможно поддерживать методами известными в индустрии. В итоге PHP сделал разворот в сторону хороших практик: ООП, типизация. Но все еще оставил часть былой легкости.
Работа
Я всегда думал, что зарплата в дотнет-мире выше, и это, в целом, правда, если судить по средней по больнице. Но есть один нюанс: на рынке катастрофически не хватает PHP-разработчиков, которые знают что такое ООП, паттерны, SOLID и умеют это использовать. Как я писал проекты выросли и обросли деньгами и кучей кода, появились фреймворки, на которых можно начинать новые проекты (Symfony, Yii, Laravel). Все это привело к увеличению спроса. И крупные успешные компании готовы платить хорошие деньги. В итоге, PHP-разработчик сейчас может претендовать даже на большие деньги при сопоставимом уровне скиллов.
Заключение
В целом язык более «магичен» ( магические методы, жонглирование при сравнении) и прощает множество ошибок. Про MS SQL vs MySQL можно пачку таких же постов написать. Значимых отличий и интересных особенностей сильно больше, чем я уже указал: конкатенация точками, трейты, интерполяция строк в двойных кавычках и т.д. Я выбрал лишь некоторые — остальные можем обсудить в комментариях.
Я рад видеть, что современный PHP 7 все больше похож на известный мне C#! Коллеги, кто до сих пор относится с пренебрежением к PHP — я ответственно заявляю, что это совсем другой язык и вы можете смело переносить свои ООП-подходы в проекты на нем.
Изучайте новые языки и технологии! Будьте лучшей версией себя!
Комментарии (63)
zzzmmtt
24.11.2017 12:18К сожалению, PHP имеет ряд недостатков, которые упрощают жизнь на простых проектах, но приводят к тому, что обычное сравнение очень часто вызывает недоумение.
Никто не запрещает использовать строгое сравнение "===", жонглирование тут будет исключено.
mayorovp
24.11.2017 12:18Передача по ссылке работает не так как в .net!
На самом деле передача по ссылке работает точно так же как в .net.
В C# 7 можно написать:
var foo = "Петя"; ref var bar = ref foo; bar = $"Меня зовут {bar}"; Console.WriteLine(foo); Console.WriteLine(bar);
В более ранних версиях языка так писать нельзя — но не потому что передача по ссылке работает как-то по-другому, а потому что она работала только для формальных и фактических параметров, а пример выше вызывал синтаксическую ошибку.
Akuma
24.11.2017 12:39Книги. Меня конечно сейчас закидают, но мне кажется что книги по PHP устаревают еще до печати. Так же как в JS, например.
yarosroman
24.11.2017 12:51Про путь C# в сторону opensource. Сейчас есть две ветки .net «старый» и .net core, так вот открыт только второй, классический dot.net остался закрытым. И для совместимости придумали net standart.
MrDaedra
24.11.2017 13:11«Старый» не развивается как opensource, но код всё-таки доступен на sourceof.net
HaVok
24.11.2017 20:26Язык программирования (C#) и фреймворк (.NET Framework или .NET Core) это разные вещи. В любом случае, всё уже открыто: C#, .NET Core, .NET Framework (частично).
FreeDobby
24.11.2017 13:37+1Хочется крикнуть БЕГИТЕ
ГОЛУБЦЫГЛУПЦЫ!!! Я сам сишарпер, но сейчас волей судьбы приходится кодить на пыхе. Я уже волосы на голове готов рвать. Это жуткий язык. Просто чудовищный. Функциональность никакая. Синтаксис ужасен (например мне просто катастрофически не хватает коротких лямбд). Говнокода в старых проектах просто океаны, причем его нечитабельность поражает (в C# так специально не напишешь). Слава богу начальник обещал следующий проект на чем-нибудь другом делать. Может даже уболтаю на C# .NET Core (сервак все-же на линуксе).
barsuksergey
24.11.2017 15:07+1Очень похоже на одну знакомую организацию, в которой по объективным причинам нельзя было переходить не то что на PHP7, а даже на PHP5.6. 5.4 forever — это ли не отделение ада?
Sovetnikov
24.11.2017 14:58Вы не написали о своём опыте работы на .NET, это сильно меняет контекст статьи.
И почему вы решили сменить стек.
Разница в языках мне кажется совершенно не важна — важно что вы перешли на стек где большое open-source комьюнити. В сравнении с .NET это огромный плюс, т.к. для .NET попробуй нади хороший сторонний компонент (пусть платный), который решит твою задачу.
Потоков дейстивтельно нехватает после C#, но всё решаемо если с головой подходить.
Я правда говорю с точки зрения перехода .NET C# (9 лет) -> Python (3 года).FreeDobby
24.11.2017 15:12Спорно, очень спорно. Интересно чего такого вы не нашли в C# что есть в пхп. В VS я просто открываю нугет, удобно интегрированный с поиском и быстрой установкой пакетов в один клик. Причем ни разу не было чтобы я не нашел там что надо. А в пыхе приходится гуглить, причем желательно что-то сразу интегрированное во фреймворк (например для Yii какой-нибудь виджет). Потом вручную копировать/вставлять в композер.жсон, запускать с консоли `composer update` (в IDE почему-то у меня не подцепляется это) и долго ждать пока он установит (хз почему, но ставит и обновляет он очень долго, по несколько минут).
Sovetnikov
24.11.2017 15:24Ну я конечно про Python говорю в большей степени, неужени в PHP так всё плохо?
Одних только готовых компонент к Django целый вагон, комплексное решение можно сделать много быстрее.
Просто есть готовые, качественные, open-source решения, которые ты можешь взять и использовать.
oxidmod
24.11.2017 16:50Вы меня поражаете. А как же порты и адаптеры?
Вот как это выглядит у меня
1. Завести в своем коде интерфейс(-ы) необходимые для решения задачи
2. Найти подходящий пакет на гитхабе (привычка, вроде как PHPStorm позволяет искать пакеты прямо с IDE)
3. Потомвручную копировать/вставлять в композер.жсон, запускать с консоли `composer update`в консоли `composer require package_name`
4. Напилить свой адаптер для пакета
5. `...`
6. Profit!doniys_a
27.11.2017 02:16Порты и адаптеры уместны, если вы используете laravel, yii или другой фреймворк, который не реализует psr стандарты. Yii это вообще отдельная, холиварная тема, в него что либо впилить без костылей нельзя, они лишь относительно недавно избавились от classmap вручную сгенеренный вместо autoload.
Если же используете symfony, то большую часть решений включаются без особых проблем, более того, все, абсолютно все фреймворки используют компоненты и symfony, и Zend framework. другое дело, что иногда автора пакетов не соблюдают стандарты psr, и создают проблемы впоследствии с портированием. Это есть, но не настолько критично, как может показаться, больше всего проблемы создают фреймворки, которые в своем движке не оставляют вариантов, кроме как от стандартов либо отречься, либо мучиться с портированием, либо мучиться с зависимостями. конфликты тоже случаются, но это везде, NuGet не исключение)
Phpstorm вполне нормально поддерживает composer из коробки
blog.jetbrains.com/phpstorm/2017/07/configuring-with-composer-in-phpstorm-2017-2
В остальном да, у Php порог входа ниже, соответственно мягко говоря некачественного кода больше, но это еще не говорит о том, что в нем нет инструментов для организации лучших практик проектирования и программирования.
Странно, но очень немного Php разработчиков, обычно уровня middle+, вообще пользуются psr интерфейсами для стандартизации кода.oxidmod
27.11.2017 08:25+1Порты и адаптеры не имеют никакого отношения к пср-ам. По хорошему ваш код должен быть изолирован от всего. От бд, от фреймворка, от ui. Можно полностью описать всю бизнес логику не имея ни бд, ни фреймворка и лишь потом подобрать инструменты, которые помогут вам лучшим образом. Запилить под них уже конкретные имплементации своих интерфейсов. Так можно сделать даже с первым yii
sayber
24.11.2017 18:57Знать бы почему разработчики в опытом 5+ лет на .net С# переходят на PHP.
Имеется один популярный Российский интернет-магазин одежды, реализованный на .net С#.
Там множество разработчиков и они довольно часто меняются.
За пару лет, человек 10-15, перешли на PHP, другие на питона, гофер и т.д.
Интересуют вопросы:
1) Почему программисты покидают C#
2) Почему многие выбирают PHP
P.S.
Сам работаю на 3х языках Go, JS, PHP
GraDea Автор
24.11.2017 21:20Иной раз выбирают не язык, а проект.
YaRobot
27.11.2017 15:13Нет, они именно выбрали PHP или Python (в большем проценте).
Хотя как мне кажется, C# уровнем выше.
Т.е. они пошли работать где проект скажем на C#, и в роли тимлидов, решили переписать на один из указаных мной языков. То ли PHP становится популярным в России, за счет улучшения ключа ООП, то ли у людей явно что то происходит в голове интересное.
Я конечно за PHP, ко людей обычно отговаривакаю, меньше конкуренции, это плюс =)
hVostt
25.11.2017 22:211) язык C# энтепрайзный, что подразумевает основательный, вдумчивый и серьёзный подход к разработке, творчество сильно урезано. уходят потому что «художники» и хотят больше творческой свободы
2) знаю только одного человека, который ушёл на PHP, причина: писать очень быстрые скрипты и на лету размещать их в интернете, проекты: реклама на сайтах, банерные сети, порно, генерация саттелитов ботнетами и подобное.
П.С. ещё по 2) если сравнить охват и распространённость PHP с C#, и свести к пропорциям, то уже никаких «многих» не будет :)
ну и для энтепрайза PHP практически совсем не подходит. поэтому надо смотреть по области задач, а не вообще.Free_ze
27.11.2017 11:111)… творчество сильно урезано
А можно пример проявления такого творчества?hVostt
27.11.2017 19:33$var_name = 'my_var'; $$var_name = 'hello';
Вот такое, например, делать в C# невозможно, соответственно не приходится контролировать и бить по рукам. Очень мало «утиной» типизации, неочевидного поведения, которое можно «творчески» эксплуатировать, с приведением типов практически нет никаких сюрпризов. В большой командной разработке строгость и сухость языка, местами многословность — то, что в динамике, типа PHP можно сделать парой строчек, в C# порой надо решать вообще отдельными структурами и классами, расширяющими методами, это огромный плюс. Для некоторых это минус.Free_ze
27.11.2017 19:57Вот такое, например, делать в C# невозможно
Сильное заявление. Как же рефлекшн? Другое дело, что кейсы для таких вещей обычно покрывают с помощью полиморфизма.
Очень мало «утиной» типизации
А как же анонимные типы?dynamic? Кортежи?
Многословно — да, но если все равно потом придется писать тесты, то здесь типобезопасность гарантируется компилятором.
Выходит, творчество — это быстрые неочевидные хаки? Но, блин, в PHP по сей день перед каждой переменной "$" (=hVostt
27.11.2017 20:05Сильное заявление. Как же рефлекшн? Другое дело, что кейсы для таких вещей обычно покрывают с помощью полиморфизма.
Рефлекшн не является рядовым инструментом для решения задач, и при его применении видно явно: это рефлекшен, т.е. такой код дополнительно требуется протестировать и зачастую можно выпилить и заменить на код без рефлекии или на Extpression-tree. Ну и полиформизм в C# это не «полиформизм», основанный на подстановке имени переменной в рантайме, компилятор может проконтролировать приведение типов в рамках иерархии наследования.
А как же анонимные типы? dynamic? Кортежи?
Я бы не назвал это утиной типизацией :)
Выходит, творчество — это хаки? Но, блин, в PHP по сей день перед каждой переменной "$" (=
Творчество, это эксплуатирование неочевидного поведения и всяких WAT для получения профита, душевного и практического :)Free_ze
28.11.2017 09:27Рефлекшн не является рядовым инструментом для решения задач
Ну это уже как минимум не «невозможно», правда?
такой код дополнительно требуется протестировать
Такой код и в php нужно тестировать. Вообще, всю такую рантаймовую магию нужно тестировать, ибо компилятор тут не всегда сможет спасти.
Я бы не назвал это утиной типизацией
Сути дела это не меняет (=
Творчество, это эксплуатирование неочевидного поведения и всяких WAT для получения профита, душевного и практического
Неочевидный код доставляет php-юзеру удовольствие?)hVostt
28.11.2017 18:14Ну это уже как минимум не «невозможно», правда?
Рефлексия — это одна из сильных сторон платформы, но в прикладном коде она встречается редко, и очень легко детектится.
Неочевидный код доставляет php-юзеру удовольствие?)
Не исключено ))Free_ze
28.11.2017 19:00Ну, как сказать… например, для использования кастомных атрибутов рефлекшн необходим. А это достаточно популярная функциональность.
Возможные ошибки там — поганы, как и любые другие рантаймовые.hVostt
28.11.2017 21:07Ну это скорее сахарный рефлекшен, и всё равно он типизированный, это уже речь идёт об аспектах, которые тоже имеют отношение к контролю за качеством и исполнению кода.
oxidmod
28.11.2017 19:08Рефлексия — это одна из сильных сторон платформы, но в прикладном коде она встречается редко, и очень легко детектится.
Рефлексия активно используется во всяких магических штуках, например в ОРМ. Доктрина активно юзает рефлексию чтобы засетить данные в приватные поля ваших сущностей.
Как по мне, то в таких вещах как раз самое место для рефлексииhVostt
28.11.2017 21:05Не-не, я абсолютно не приветствую в любых формах доступ к приватным полям, это косяк в архитектуре. А в рефлексии удобно собирать динамические вызовы хендлеров для команд, запросов, событий. Сейчас пилим CQRS, без рефлексии никуда :)
mayorovp
28.11.2017 08:51Утиная типизация — это как работают операторы foreach и await. В анонимных типах и кортежах нет никакой утиной типизации, анонимный тип или кортеж — это строго определенный тип данных.
dynamic может использоваться для утиной типизации.
VolCh
27.11.2017 16:08ну и для энтепрайза PHP практически совсем не подходит
Что вы имеете в виду? Чем не подходит?
hVostt
27.11.2017 19:38Не подходит тем, что одна и та же задача в PHP может быть решена 100 разработчиками совершенно разными 100 способами. В C# профессионалы одного уровня решат её примерно одинаково, соответственно большой команде не надо долго и упорно договариваться, код получается единообразным, понятным, контролируемым, практически полностью очевидным и предсказуемым. Но такой код пишется большими усилиями и с гораздо более высокими требованиями к профессионализму, зато сопровождается дешевле. Ну и не видел я серьёзного присутствия PHP в энтерпрайзе, только на периферии.
Assada
27.11.2017 20:21решена 100 разработчиками совершенно разными 100 способами
Очень спорно. Как тут PHP замешан? Откуда такая инфа?hVostt
27.11.2017 20:35Ну давайте не придираться к словам, естественно никто не брал 100 разработчиков и не изучал их 100 решений, это небольшое вольное утрирование. Честно говоря, не вижу смысла холиворить, я высказал свои соображения, основанные на опыте и наблюдениях, не в целях кому-то что-то доказать. Тем более я уверен, что на любом языке можно писать как плохо, так и хорошо. Но PHP предоставляет очень много вольностей, и мне видится не эффективным обустраивать разработку на большом количестве гайдов и договорённостей, в то время как в C# имеется единый для всех гайд, прививаемый с самых пелёнок и компилятор не даёт наделать большое количество ошибок, которые можно легко наделать в PHP.
VolCh
28.11.2017 07:06А что за единый гайд, прививаемый с пелёнок? Я помнится году в так в 2000-м использовал немного Visual C# на одном проекте и году так в 2009-м Mono на другом и что-то единого гайда не помню.
hVostt
28.11.2017 18:18Единый гайд описан на страницах MSDN, описан один к одному во всех книгах и упоминается в статьях, прослеживается в 90% существующей кодовой базы. Его и помнить не надо, так как если вы разрабатываете на C#, то уже скорее всего придерживаетесь этого гайда, если только вы не перешли с другого языка и тащите свои привычки в чужое поле.
VolCh
28.11.2017 07:44+1100 способов сильно ограничиваются решениями использовать тот или иной фреймворк, ту или иную инфраструктуру. Как, скажем, в мире .NET принимают решение использовать ASP.NET WebForms, а не ASP.NET MVC и некоторые способы становятся если не недоступными, то нерациональными, а профессионалі садятся за гайды, потому что никогда не сталкивались, но всё равно по факту протаскивают "неправильные" способы. А решение использовать MySQL, а не MS SQL может привести к тому, что C# разработчики отказываются с ним работать из-за того, что что-то там не поддерживается на уровне то ли .NET библиотек, то ли Windows, а SQL код писать они не привычные. Вернее не знают как сделать из SQL-запроса граф обычных объектов и потому просят DBA на стороне MS SQL написать шлюз к MySQL.
Но вообще речь не о C#, а о PHP. Как я понял, основные причина вывода "для энтепрайза PHP практически совсем не подходит" у вас это отсутствие единого гайда и отстутствие статической типизации? Я бы прежде всего назвал отсуствие явного лидера среди фреймворков, даже если брать чисто ентерпрайз сегмент — как минимум нужно будет делать выбор между Symfony и Zend.
hVostt
28.11.2017 18:26Основная причина, как мне видится, — это слабый контроль за качеством кода со стороны компилятора и инструментов разработки, безопасность полностью ложится на плечи разработчика, нет единых интерфейсов и базы, на которую бы ложились существующие решения. Очень много возможностей прострелить себе ногу у PHP. Честно говоря, не хочу повторяться, об этом уже миллион раз говорилось, и языком гораздо богаче и литературнее, чем у меня :)
Symphony и Zend — прекрасные фреймворки, я не буду спорить. Но факт остаётся фактом, я практически не видел присутствия PHP в энтерпрайзе. Какие-нибудь корпоративные порталы не в счёт.
hVostt
28.11.2017 18:29Решение использовать MySQL, а не MS SQL, вообще играет ничтожную роль. Если решение написано и ложится в рамки Entity Framework, то оно будет работать одинаково и на MS SQL, и на MySQL, и на Postgres, и на Oracle. Поэтому «C# разработчики отказываются» — это какая-то ересь если честно. Сегодня C# разработчики очень активно пользуются докер-контейнерами и активно дружат с кроссплатформенной разработкой.
VolCh
24.11.2017 19:58Конкатенация точкой точно не то, что стоит обсуждать. Кажется в статических языках нет возможности (без рефлексии) собирать имена классов, методов, свойств из строк, включая пользовательский ввод и использовать их как обычные.
В PHP нет модулей, увы.
KvanTTT
25.11.2017 04:33А чем рефлексия не угодила? В C# есть dynamic, которые разрешают кастомные свойства и "использовать их как обычные".
VolCh
26.11.2017 19:00Я не про кастомные свойства, а про конструкции типа
$className = $_GET['module'] . 'Controller'; $methodName = $_GET['action'] . 'Action'; $result = (new $className)->{$someMethod}();zzzmmtt
27.11.2017 10:14+1У вас ошибочка, вы это хотели написать?
$className = $_GET['module'] . 'Controller'; $methodName = $_GET['action'] . 'Action'; $result = (new $className)->{$methodName}();VolCh
27.11.2017 10:16Да. Сначла один вариант был, потом исправил, но текстареа хабра переименования переменной не отследиила :)
andboson
25.11.2017 12:09Буки:
* PHP: объекты, шаблоны и методики программирования. Мэтт Зандстра
* Josh Lockhart Modern PHP. New Features and Good Practices
* ну и phptherightway.com (с кучей ссылок)GraDea Автор
26.11.2017 15:31Про первую написал — ждем весной новое издание.
Выбирал между Локхартом и Котеровым, остановился на втором. Сейчас уже не вспомню почему.
Rightway — отличный ресурс.
ivorobioff
25.11.2017 12:12Могу добавить что в PHP пока еще не хватает ламбды, дженериков и типизированных массивов. Может быть к php7.5 что-то из этого добавится.
oxidmod
php.net/manual/en/spl.datastructures.php
AotD
Да, но фактически я встречал оочень мало фреймворков/проектов в которых эти структуры применялись бы активно.
A1essandro
Но это не мешает применять их Вам. Хотя для меня, человека который начинал с PHP, а сейчас работающего с C#, довольно странный путь PHP->C#. Иногда, когда я касаюсь разработки на PHP, мне очень не хватает той мощности C# (особенно встроенного linq и генериков). Ну и «магичность» PHP…
A1essandro
Конечно, я ошибся. Извиняюсь. Странный путь C# -> PHP. Хотя, конечно, я не в курсе сложившейся ситуации. При определенных обстоятельствах такой путь будет хорошим решением.
Akuma
Да, потому что 99% функционала можно покрыть обычными массивами. А учитывая, что PHP «создан чтобы умирать», то какие-то микро-оптимизации SPL довольно бессмысленны.
Хотя, у меня есть демон который использует SplObjectStorage и это довольно удобно. Правда не замерял скорость/память по сранению с обычными массивами, но не думаю, что что-то сильно бы поменялось.
Assada
Тут немного тестов есть: habrahabr.ru/post/337298
Akuma
Спасибо. Действительно на больших объемах Spl кушает меньше памяти и вроде как пошустрее.
alekciy
Автор ещё видимо не открыл для себя DS из 7-км. Очень надеюсь, что, как когда-то и fpm, перетащат в «из коробки»