VZVZ С точки зрения фронта - таки транспортный (HyperText Transfer Protocol), безусловно, по модели OSI 'nj не так.
@ulrich-schnauss
> Я так понял Вы опытный бэкендщик, Лично Вы как пишете бэкенды?
Под каждый проект проектирую архитектуру на основании требований к проекту. Между фронтом и бэком пишется спецификация протокола общения, далее бэк делается отдельно, фронт тоже отдельно.
> как организовываете связь с фронтендом?
фронт делает запросы, согласно утвержденному протоколу. Бэк отвечает на эти запросы, опять же согласно протоколу
@nazarpc
Да не вопрос)) Для сложных систем с нетривиальным стеком LEMP, а еще всякими ELK, Mongo, Graphite,... Когда будете настраивать рабочую машину - вспомните про vagrant))
27cm
Это тот случай, когда овчинка выделки стоит, да вы получаете оверхед по проверкам, но взамен получаете намного больше.
На счет тестов - все верно, только ими стоит покрывать вне зависимости от наличия проверок.
> Если лепить проверки буквально во все методы, причем даже там, где они никогда не выстрелят
Когда работаешь в большой команде, понятия "никогда не выстрелит | вызовется | произойдет |..." становятся не содержательным бла-бла-бла, увы.
Код крупного проекта не пишется один раз, он меняется и развивается.
Стектрейс читать придется в любом случае.
Даже если бросать как в примере с методом test, что вы узнаете из исключения? То, что метод вызван с не правильным аргументом, откуда вызвался? При каких условиях и т.д. это все равно будет содержаться в стектрейсе.
Мне жаль вас расстраивать, но статья не особо актуальна. mysq_** - уже давно deprecated. Подстановка полей конкатенацией, или через вставку переменной в строку - это в принципе хреновый подход, так нельзя делать, используйте плейсхолдеры.
На счет фильтрации: как правило она нужна при выводе текстовых полей, для которых нет возможности реализовать более жесткие проверки (примеры более жестких проверок я привел выше). Шаблонизаторы типа Smarty, Twig с этим вполне отлично справляются на этапе вывода.
Глобальные переменные - это в принципе плохо))
Альтернатива - DI: IoC, как подход к построению зависимостей ваших классов. При этом за уровень доступа отвечает конкретный объект с методами проверки и установки прав
После того, как сделаете нечто - публикуйте на github, и на этом сервисе указывайте в код пальцем, если что-то не ясно, или просто для проверки, может вы какулю написали, но не замечаете))
Вам понадобится dev окружение:
1. уметь в git
2. уметь в github.com
3. https://www.youtube.com/watch?v=3WldiUHkFnw - тут смотрим, как поднимать vagrant
4. Если вы под виндой - мои соболезнования (чем раньше перейдете на ubuntu, или любой другой линушный дистрибутив - тем вам же будет легче)
5. если работаете в vim/notepad++/netBeans - нахрен это говно, на данный момент самая-самая IDE под php - phpStorm. + плагины под симфони:
* Symfony2 Plugin
* Symfony2 - Clickable Views
* PHP Annotations
Теперь уже ближе к коду:
Для начала почитайте symfony.com/doc/current/book/index.html попытайтесь проникнуться.
Далее напишите какую-то web систему, например систему заметок. Для начала для одного пользователя, без проверки доступа.
Потом сделайте ее многопользовательской и уже постигайте symfony security level.
угу, только не в конструкторе. Задача конструктора - имплементация особенностей создания требуемого объекта. Конкретно уровень доступа стоит вынести в отдельный сервис, а с экшнов его только вызывать.