@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.
угу, только не в конструкторе. Задача конструктора - имплементация особенностей создания требуемого объекта. Конкретно уровень доступа стоит вынести в отдельный сервис, а с экшнов его только вызывать.
Niomin
Вы терминологию путаете((.
/show/{id} - это роут
{id} - это атрибут запроса
Контроллер - это класс для экшнов
Экшн - это метод (или класс с фиксированным методом run например), который мапится роутером на роут.
@vlad6085
> Как на практике реализуются приложения, основанные на микросервисах?
Проектируется и реализуется)) Почитайте Сэма Ньюмана "Создание микросервисов"
> Для каждого из них поднимается свой mysql? Или для каждого из них существует своя БД/таблица?
В зависимости от требований к проекту. Безопасней - отадельные БД, так как это обеспечит защиту от бесконтрольной связности проекта.
@mikserok
> А вы сами понимаете эти определения? В вашей терминологии найдена косвеная рекурсия.
Да не вопрос. Видимо у вас есть определения по точнее))
@vlad6085
> Т.е. подразумевается что оно внутреннее, а не внешнее, я так понял.
Если это встравиваемый сервис - внутреннее, если сетевой - внешнее.
> А можно пример "самодостаточного функционала" для понимания?
Сервис отправки почты. API может быть на базе обычной очереди в rabbitmq. Все, что делает эта система - это получает шаблон письма, вставляет туда данные и отправляет.
или
Сервис защиты от мата. Все что он делает - получив на вход сообщение, проверяет его туевой хучей регулярок, и возвращает ответ: "блокировать"/"не блокировать"/"нужна ручная проверка"
@mikserok
> А зачем вообще нужны эти сравнительно новые термины - микросервисы, система, самодостаточный функционал?
Термины нужны для именования вещей и событий))
> Какая от них практическая польза? Просто пишите как писали раньше.
Ну, когда ваш проект не помещается на 10 физических серверов и более - писать как писал не особо то получится))
Да не вопрос)) Для сложных систем с нетривиальным стеком LEMP, а еще всякими ELK, Mongo, Graphite,... Когда будете настраивать рабочую машину - вспомните про vagrant))