Путь разработчика ASP.NET → PHP

    Так получилось, что в сентябре прошлого года назад я перешел в компанию, где основным языком бэкенд-разработки был PHP 7. До этого технологии с которыми я работал ограничивались C#, ASP.NET, Javascript (JQuery, Angular 1.x, Typescript), MS SQL, IIS и Windows Server. Теперь же предстояло погружение в новый стек. Данная статьи — не очередной наброс на вентилятор для поддержки холивара. Постараюсь отметить, что показалось необычным или непривычным. Статья обращена к .net разработчикам, но, надеюсь, будет интересна и PHP сообществу.
    image

    Начнем с сессии


    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 — я ответственно заявляю, что это совсем другой язык и вы можете смело переносить свои ООП-подходы в проекты на нем.

    Изучайте новые языки и технологии! Будьте лучшей версией себя!
    Поделиться публикацией
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама
    Комментарии 74
    • 0
      В PHP есть только ассоциативный массив


      php.net/manual/en/spl.datastructures.php
      • +1
        Да, но фактически я встречал оочень мало фреймворков/проектов в которых эти структуры применялись бы активно.
        • +1
          Но это не мешает применять их Вам. Хотя для меня, человека который начинал с PHP, а сейчас работающего с C#, довольно странный путь PHP->C#. Иногда, когда я касаюсь разработки на PHP, мне очень не хватает той мощности C# (особенно встроенного linq и генериков). Ну и «магичность» PHP…
          • 0
            Конечно, я ошибся. Извиняюсь. Странный путь C# -> PHP. Хотя, конечно, я не в курсе сложившейся ситуации. При определенных обстоятельствах такой путь будет хорошим решением.
          • 0
            Да, потому что 99% функционала можно покрыть обычными массивами. А учитывая, что PHP «создан чтобы умирать», то какие-то микро-оптимизации SPL довольно бессмысленны.

            Хотя, у меня есть демон который использует SplObjectStorage и это довольно удобно. Правда не замерял скорость/память по сранению с обычными массивами, но не думаю, что что-то сильно бы поменялось.
            • 0
              Тут немного тестов есть: habrahabr.ru/post/337298
              • 0
                Спасибо. Действительно на больших объемах Spl кушает меньше памяти и вроде как пошустрее.
          • +1
            Автор ещё видимо не открыл для себя DS из 7-км. Очень надеюсь, что, как когда-то и fpm, перетащат в «из коробки»
          • +2
            К сожалению, PHP имеет ряд недостатков, которые упрощают жизнь на простых проектах, но приводят к тому, что обычное сравнение очень часто вызывает недоумение.

            Никто не запрещает использовать строгое сравнение "===", жонглирование тут будет исключено.
            • +1
              Передача по ссылке работает не так как в .net!

              На самом деле передача по ссылке работает точно так же как в .net.


              В C# 7 можно написать:


              var foo = "Петя";
              ref var bar = ref foo;
              bar = $"Меня зовут {bar}";
              
              Console.WriteLine(foo);
              Console.WriteLine(bar);

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

              • 0
                Да, похоже, что я напутал. Поправлю.
              • +4
                Книги. Меня конечно сейчас закидают, но мне кажется что книги по PHP устаревают еще до печати. Так же как в JS, например.
                • 0
                  Про путь C# в сторону opensource. Сейчас есть две ветки .net «старый» и .net core, так вот открыт только второй, классический dot.net остался закрытым. И для совместимости придумали net standart.
                  • +2
                    «Старый» не развивается как opensource, но код всё-таки доступен на sourceof.net
                    • 0
                      Говоря про пивот к опенсорсу, я имел ввиду кучу всего на гитхабе.
                      • 0
                        Язык программирования (C#) и фреймворк (.NET Framework или .NET Core) это разные вещи. В любом случае, всё уже открыто: C#, .NET Core, .NET Framework (частично).
                      • +7
                        Хочется крикнуть БЕГИТЕ ГОЛУБЦЫ ГЛУПЦЫ!!! Я сам сишарпер, но сейчас волей судьбы приходится кодить на пыхе. Я уже волосы на голове готов рвать. Это жуткий язык. Просто чудовищный. Функциональность никакая. Синтаксис ужасен (например мне просто катастрофически не хватает коротких лямбд). Говнокода в старых проектах просто океаны, причем его нечитабельность поражает (в C# так специально не напишешь). Слава богу начальник обещал следующий проект на чем-нибудь другом делать. Может даже уболтаю на C# .NET Core (сервак все-же на линуксе).
                        • +3
                          Очень похоже на одну знакомую организацию, в которой по объективным причинам нельзя было переходить не то что на PHP7, а даже на PHP5.6. 5.4 forever — это ли не отделение ада?
                          • +2
                            Ну так если вы — сишарпер, просто не пишите на пхп ;)
                          • +1
                            Вы не написали о своём опыте работы на .NET, это сильно меняет контекст статьи.
                            И почему вы решили сменить стек.

                            Разница в языках мне кажется совершенно не важна — важно что вы перешли на стек где большое open-source комьюнити. В сравнении с .NET это огромный плюс, т.к. для .NET попробуй нади хороший сторонний компонент (пусть платный), который решит твою задачу.

                            Потоков дейстивтельно нехватает после C#, но всё решаемо если с головой подходить.

                            Я правда говорю с точки зрения перехода .NET C# (9 лет) -> Python (3 года).
                            • 0
                              Спорно, очень спорно. Интересно чего такого вы не нашли в C# что есть в пхп. В VS я просто открываю нугет, удобно интегрированный с поиском и быстрой установкой пакетов в один клик. Причем ни разу не было чтобы я не нашел там что надо. А в пыхе приходится гуглить, причем желательно что-то сразу интегрированное во фреймворк (например для Yii какой-нибудь виджет). Потом вручную копировать/вставлять в композер.жсон, запускать с консоли `composer update` (в IDE почему-то у меня не подцепляется это) и долго ждать пока он установит (хз почему, но ставит и обновляет он очень долго, по несколько минут).
                              • 0
                                Ну я конечно про Python говорю в большей степени, неужени в PHP так всё плохо?
                                Одних только готовых компонент к Django целый вагон, комплексное решение можно сделать много быстрее.
                                Просто есть готовые, качественные, open-source решения, которые ты можешь взять и использовать.
                                • +3
                                  Вы меня поражаете. А как же порты и адаптеры?
                                  Вот как это выглядит у меня

                                  1. Завести в своем коде интерфейс(-ы) необходимые для решения задачи
                                  2. Найти подходящий пакет на гитхабе (привычка, вроде как PHPStorm позволяет искать пакеты прямо с IDE)
                                  3. Потом вручную копировать/вставлять в композер.жсон, запускать с консоли `composer update`в консоли `composer require package_name`
                                  4. Напилить свой адаптер для пакета
                                  5. `...`
                                  6. Profit!
                                  • 0
                                    Порты и адаптеры уместны, если вы используете 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 интерфейсами для стандартизации кода.
                                    • +1
                                      Порты и адаптеры не имеют никакого отношения к пср-ам. По хорошему ваш код должен быть изолирован от всего. От бд, от фреймворка, от ui. Можно полностью описать всю бизнес логику не имея ни бд, ни фреймворка и лишь потом подобрать инструменты, которые помогут вам лучшим образом. Запилить под них уже конкретные имплементации своих интерфейсов. Так можно сделать даже с первым yii
                              • +2
                                Знать бы почему разработчики в опытом 5+ лет на .net С# переходят на PHP.
                                Имеется один популярный Российский интернет-магазин одежды, реализованный на .net С#.
                                Там множество разработчиков и они довольно часто меняются.
                                За пару лет, человек 10-15, перешли на PHP, другие на питона, гофер и т.д.

                                Интересуют вопросы:
                                1) Почему программисты покидают C#
                                2) Почему многие выбирают PHP

                                P.S.
                                Сам работаю на 3х языках Go, JS, PHP
                                • 0
                                  Иной раз выбирают не язык, а проект.
                                  • 0
                                    Но не так же массово! Самому крайне любопытно.
                                    • 0
                                      Нет, они именно выбрали PHP или Python (в большем проценте).
                                      Хотя как мне кажется, C# уровнем выше.
                                      Т.е. они пошли работать где проект скажем на C#, и в роли тимлидов, решили переписать на один из указаных мной языков. То ли PHP становится популярным в России, за счет улучшения ключа ООП, то ли у людей явно что то происходит в голове интересное.

                                      Я конечно за PHP, ко людей обычно отговаривакаю, меньше конкуренции, это плюс =)
                                    • +1
                                      1) язык C# энтепрайзный, что подразумевает основательный, вдумчивый и серьёзный подход к разработке, творчество сильно урезано. уходят потому что «художники» и хотят больше творческой свободы
                                      2) знаю только одного человека, который ушёл на PHP, причина: писать очень быстрые скрипты и на лету размещать их в интернете, проекты: реклама на сайтах, банерные сети, порно, генерация саттелитов ботнетами и подобное.

                                      П.С. ещё по 2) если сравнить охват и распространённость PHP с C#, и свести к пропорциям, то уже никаких «многих» не будет :)

                                      ну и для энтепрайза PHP практически совсем не подходит. поэтому надо смотреть по области задач, а не вообще.
                                      • 0
                                        1)… творчество сильно урезано

                                        А можно пример проявления такого творчества?
                                        • 0
                                          $var_name = 'my_var';
                                          $$var_name = 'hello';
                                          


                                          Вот такое, например, делать в C# невозможно, соответственно не приходится контролировать и бить по рукам. Очень мало «утиной» типизации, неочевидного поведения, которое можно «творчески» эксплуатировать, с приведением типов практически нет никаких сюрпризов. В большой командной разработке строгость и сухость языка, местами многословность — то, что в динамике, типа PHP можно сделать парой строчек, в C# порой надо решать вообще отдельными структурами и классами, расширяющими методами, это огромный плюс. Для некоторых это минус.
                                          • 0
                                            Вот такое, например, делать в C# невозможно
                                            Сильное заявление. Как же рефлекшн? Другое дело, что кейсы для таких вещей обычно покрывают с помощью полиморфизма.

                                            Очень мало «утиной» типизации
                                            А как же анонимные типы? dynamic? Кортежи?

                                            Многословно — да, но если все равно потом придется писать тесты, то здесь типобезопасность гарантируется компилятором.

                                            Выходит, творчество — это быстрые неочевидные хаки? Но, блин, в PHP по сей день перед каждой переменной "$" (=
                                            • 0
                                              Сильное заявление. Как же рефлекшн? Другое дело, что кейсы для таких вещей обычно покрывают с помощью полиморфизма.


                                              Рефлекшн не является рядовым инструментом для решения задач, и при его применении видно явно: это рефлекшен, т.е. такой код дополнительно требуется протестировать и зачастую можно выпилить и заменить на код без рефлекии или на Extpression-tree. Ну и полиформизм в C# это не «полиформизм», основанный на подстановке имени переменной в рантайме, компилятор может проконтролировать приведение типов в рамках иерархии наследования.

                                              А как же анонимные типы? dynamic? Кортежи?


                                              Я бы не назвал это утиной типизацией :)

                                              Выходит, творчество — это хаки? Но, блин, в PHP по сей день перед каждой переменной "$" (=


                                              Творчество, это эксплуатирование неочевидного поведения и всяких WAT для получения профита, душевного и практического :)
                                              • 0
                                                Рефлекшн не является рядовым инструментом для решения задач
                                                Ну это уже как минимум не «невозможно», правда?

                                                такой код дополнительно требуется протестировать
                                                Такой код и в php нужно тестировать. Вообще, всю такую рантаймовую магию нужно тестировать, ибо компилятор тут не всегда сможет спасти.

                                                Я бы не назвал это утиной типизацией
                                                Сути дела это не меняет (=

                                                Творчество, это эксплуатирование неочевидного поведения и всяких WAT для получения профита, душевного и практического
                                                Неочевидный код доставляет php-юзеру удовольствие?)
                                                • 0
                                                  Ну это уже как минимум не «невозможно», правда?

                                                  Рефлексия — это одна из сильных сторон платформы, но в прикладном коде она встречается редко, и очень легко детектится.
                                                  Неочевидный код доставляет php-юзеру удовольствие?)

                                                  Не исключено ))
                                                  • 0
                                                    Ну, как сказать… например, для использования кастомных атрибутов рефлекшн необходим. А это достаточно популярная функциональность.
                                                    Возможные ошибки там — поганы, как и любые другие рантаймовые.
                                                    • 0
                                                      Ну это скорее сахарный рефлекшен, и всё равно он типизированный, это уже речь идёт об аспектах, которые тоже имеют отношение к контролю за качеством и исполнению кода.
                                                      • 0
                                                        Это уже демагогия)
                                                        Если говорить вне контекста, то если есть типизация и она не мешает выполнять задачу, то было бы глупо ее не использовать. Нужна гибкость, стоящая тормозов и магического кода? Тогда рефлекшн и dynamic.
                                                    • 0
                                                      Рефлексия — это одна из сильных сторон платформы, но в прикладном коде она встречается редко, и очень легко детектится.


                                                      Рефлексия активно используется во всяких магических штуках, например в ОРМ. Доктрина активно юзает рефлексию чтобы засетить данные в приватные поля ваших сущностей.
                                                      Как по мне, то в таких вещах как раз самое место для рефлексии
                                                      • 0
                                                        Не-не, я абсолютно не приветствую в любых формах доступ к приватным полям, это косяк в архитектуре. А в рефлексии удобно собирать динамические вызовы хендлеров для команд, запросов, событий. Сейчас пилим CQRS, без рефлексии никуда :)
                                                        • 0
                                                          А какую альтернативу вы предлагаете для ОРМок? Пилить сеттеры на каждое поле сущности?
                                                          Хотя MSDN это и предлагает, да.

                                                          Сейчас пилим CQRS, без рефлексии никуда :)

                                                          Мы похоже о разном говорим. Вы на чем пилите CQRS? Мы вот на пыхе пилим. За основу взяли вот этот команд бас в паре с соотвествующим бандлом для симфони. Там можно находить хендлеры как с помощью рефлексии, так и с помощью простого конфига маппинга. По понятным причинам рефлексию мы не юзаем там.
                                                          • 0
                                                            ОРМ-ки могут прекрасно работать с POCO, это наиболее правильный путь, я считаю. Сущности в понятиях DDD, всё равно отвратительно ложатся на ORM, и все попытки это сделать, которые я наблюдал за много лет, это просто курам на смех :) Поэтому ORM надо оставить то, для чего оно было придумано.

                                                            Мы пилим на C#, за основу ничего взять не получилось, пилим с нуля. В пыхе проще, там типизация утиная, поэтому можно вызвать handle с одним аргументом у любого класса. В C# тотальный контроль типов, и класс хендлера должен реализовывать интерфейс хендлера с типом-командой, чтобы найти хендлер, надо в рефлексии сформировать тип хендлера, затем получать его через DI. Т.е. какой-то особенный конфиг-мап не нужен, просто регистрируем свои хендлеры в DI и всё.
                                                            • 0

                                                              А в чём выражается "отвратительно"?

                                                              • +1
                                                                В пыхе проще, там типизация утиная, поэтому можно вызвать handle с одним аргументом у любого класса.

                                                                void CallHandler(dynamic obj) {
                                                                    var arg = ...
                                                                    obj.Handle(arg);
                                                                }
                                                                • 0
                                                                  Только на самом деле так лучше не делать. dynamic не так шустро работает если ему постоянно разные классы на вход совать…
                                                                  • 0
                                                                    По крайней мере есть выбор. Хотя, лучше бы в C# нормальные статические шаблоны были, кмк.
                                                  • 0

                                                    Утиная типизация — это как работают операторы foreach и await. В анонимных типах и кортежах нет никакой утиной типизации, анонимный тип или кортеж — это строго определенный тип данных.


                                                    dynamic может использоваться для утиной типизации.

                                              • 0
                                                ну и для энтепрайза PHP практически совсем не подходит

                                                Что вы имеете в виду? Чем не подходит?

                                                • 0
                                                  Не подходит тем, что одна и та же задача в PHP может быть решена 100 разработчиками совершенно разными 100 способами. В C# профессионалы одного уровня решат её примерно одинаково, соответственно большой команде не надо долго и упорно договариваться, код получается единообразным, понятным, контролируемым, практически полностью очевидным и предсказуемым. Но такой код пишется большими усилиями и с гораздо более высокими требованиями к профессионализму, зато сопровождается дешевле. Ну и не видел я серьёзного присутствия PHP в энтерпрайзе, только на периферии.
                                                  • 0
                                                    решена 100 разработчиками совершенно разными 100 способами

                                                    Очень спорно. Как тут PHP замешан? Откуда такая инфа?
                                                    • 0
                                                      Ну давайте не придираться к словам, естественно никто не брал 100 разработчиков и не изучал их 100 решений, это небольшое вольное утрирование. Честно говоря, не вижу смысла холиворить, я высказал свои соображения, основанные на опыте и наблюдениях, не в целях кому-то что-то доказать. Тем более я уверен, что на любом языке можно писать как плохо, так и хорошо. Но PHP предоставляет очень много вольностей, и мне видится не эффективным обустраивать разработку на большом количестве гайдов и договорённостей, в то время как в C# имеется единый для всех гайд, прививаемый с самых пелёнок и компилятор не даёт наделать большое количество ошибок, которые можно легко наделать в PHP.
                                                      • 0

                                                        А что за единый гайд, прививаемый с пелёнок? Я помнится году в так в 2000-м использовал немного Visual C# на одном проекте и году так в 2009-м Mono на другом и что-то единого гайда не помню.

                                                        • 0
                                                          Единый гайд описан на страницах MSDN, описан один к одному во всех книгах и упоминается в статьях, прослеживается в 90% существующей кодовой базы. Его и помнить не надо, так как если вы разрабатываете на C#, то уже скорее всего придерживаетесь этого гайда, если только вы не перешли с другого языка и тащите свои привычки в чужое поле.
                                                    • +1

                                                      100 способов сильно ограничиваются решениями использовать тот или иной фреймворк, ту или иную инфраструктуру. Как, скажем, в мире .NET принимают решение использовать ASP.NET WebForms, а не ASP.NET MVC и некоторые способы становятся если не недоступными, то нерациональными, а профессионалі садятся за гайды, потому что никогда не сталкивались, но всё равно по факту протаскивают "неправильные" способы. А решение использовать MySQL, а не MS SQL может привести к тому, что C# разработчики отказываются с ним работать из-за того, что что-то там не поддерживается на уровне то ли .NET библиотек, то ли Windows, а SQL код писать они не привычные. Вернее не знают как сделать из SQL-запроса граф обычных объектов и потому просят DBA на стороне MS SQL написать шлюз к MySQL.


                                                      Но вообще речь не о C#, а о PHP. Как я понял, основные причина вывода "для энтепрайза PHP практически совсем не подходит" у вас это отсутствие единого гайда и отстутствие статической типизации? Я бы прежде всего назвал отсуствие явного лидера среди фреймворков, даже если брать чисто ентерпрайз сегмент — как минимум нужно будет делать выбор между Symfony и Zend.

                                                      • 0
                                                        Основная причина, как мне видится, — это слабый контроль за качеством кода со стороны компилятора и инструментов разработки, безопасность полностью ложится на плечи разработчика, нет единых интерфейсов и базы, на которую бы ложились существующие решения. Очень много возможностей прострелить себе ногу у PHP. Честно говоря, не хочу повторяться, об этом уже миллион раз говорилось, и языком гораздо богаче и литературнее, чем у меня :)

                                                        Symphony и Zend — прекрасные фреймворки, я не буду спорить. Но факт остаётся фактом, я практически не видел присутствия PHP в энтерпрайзе. Какие-нибудь корпоративные порталы не в счёт.
                                                        • +1
                                                          инструментов разработки

                                                          Вы просто о них не знаете. Они есть и используются повсеместно. Например: github.com/squizlabs/PHP_CodeSniffer
                                                          github.com/phan/phan

                                                          практически не видел

                                                          Опять же, это не означает что их нет. А они есть, поверьте.
                                                          • 0

                                                            Всё зависит от желания использовать средства контроля качества кода, как встроенные в референсную реализацию языка (например type hinting и strict режим), так и сторонние.

                                                          • 0
                                                            Решение использовать MySQL, а не MS SQL, вообще играет ничтожную роль. Если решение написано и ложится в рамки Entity Framework, то оно будет работать одинаково и на MS SQL, и на MySQL, и на Postgres, и на Oracle. Поэтому «C# разработчики отказываются» — это какая-то ересь если честно. Сегодня C# разработчики очень активно пользуются докер-контейнерами и активно дружат с кроссплатформенной разработкой.
                                                            • 0

                                                              Посмотрел переписку давнюю, кажется дело было в ODBC-драйвере MySQL, что-то мы активно использовали, о чём ODBC не знал, а без него, просто через libmysqlclient C# разработчики отказывались работать с MySQL. В чём точно проблема не могу сказать.

                                                  • 0
                                                    Конкатенация точкой точно не то, что стоит обсуждать. Кажется в статических языках нет возможности (без рефлексии) собирать имена классов, методов, свойств из строк, включая пользовательский ввод и использовать их как обычные.

                                                    В PHP нет модулей, увы.
                                                    • 0
                                                      А откуда сразу условие — без рефлексии? :-)
                                                      • 0

                                                        Потому что в PHP это можно делать без рефлексии :)

                                                        • 0
                                                          А теперь попробуйте сделать то же самое без косвенного обращения к переменным, классам и методам! Потому что в C# это делается без него :-)
                                                      • 0

                                                        А чем рефлексия не угодила? В C# есть dynamic, которые разрешают кастомные свойства и "использовать их как обычные".

                                                        • 0

                                                          Я не про кастомные свойства, а про конструкции типа


                                                          $className = $_GET['module'] . 'Controller'; 
                                                          $methodName = $_GET['action'] . 'Action';
                                                          $result = (new $className)->{$someMethod}(); 
                                                          • +1
                                                            У вас ошибочка, вы это хотели написать?
                                                            $className = $_GET['module'] . 'Controller'; 
                                                            $methodName = $_GET['action'] . 'Action';
                                                            $result = (new $className)->{$methodName}(); 
                                                            • 0

                                                              Да. Сначла один вариант был, потом исправил, но текстареа хабра переименования переменной не отследиила :)

                                                      • 0
                                                        <комментарий удалён>
                                                        • 0
                                                          Буки:
                                                          * PHP: объекты, шаблоны и методики программирования. Мэтт Зандстра
                                                          * Josh Lockhart Modern PHP. New Features and Good Practices
                                                          * ну и phptherightway.com (с кучей ссылок)
                                                          • 0
                                                            Про первую написал — ждем весной новое издание.
                                                            Выбирал между Локхартом и Котеровым, остановился на втором. Сейчас уже не вспомню почему.
                                                            Rightway — отличный ресурс.
                                                            • 0
                                                              Локхарта однозначно стоит почитать, потому что там соль именно современной разработки на ПХП.
                                                          • 0
                                                            Могу добавить что в PHP пока еще не хватает ламбды, дженериков и типизированных массивов. Может быть к php7.5 что-то из этого добавится.
                                                            • +2
                                                              Лямды есть. Только с явным захватом контекста. Как в C++.

                                                            Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.