heartdevil

Я не знаю ни laravel ни symfony, но может идейно помогу.
Кода, скорее всего, будет больше, просто потому что вы все пишете сами. Меньше может стать только если вы что-то там доустановите в симфони и будете пользоваться этой надстройкой. Но идейно, у вас есть уже разделение на репозитории и вам нужен еще один слой бизнес логики. Вы можете и бизнес логику хранить в репозиториях, но тогда вопрос, а зачем вообще нужен этот слой репозиториев, если все можно хранить в контроллерах :). Вообще, репозитории должны быть как можно более общими. Какие-то простые запросы в базу типа, вернуть все или вернуть все у чего id равен чему-то. Такие вещи как флаги или сортировка, тоже можно уже сразу встроить в запросы, но обычно флаги - это уже бизнес логика. Так же как и какая-то кастомная сортировка. Для тких "хитрых" запросов обычно выделяется еще один слой. Бизнес-логика. К примеру, называем его Services и туда пробрасываем нашим репозитории и на основе них уже делаются методы типа GetActiveSoretedFilteredAndSoOnService. Ну и далее сервисы пробрасываются в контроллеры и конроллеры знают только про них. А про контроллеры вы правильно заметили. Такую логику переключений лучше там не держать. Хотя бывает разное. Да и вопрос, а зачем так переключать запросы в контроллере? В чем выгода? Может лучше на каждый пункт меню сделать отдельный метод get в контроллере? Или это специфика symfony? Что все через index надо делать.

Люблю сейчас смотреть на такие ситуации. Не злорадно :), конечно. Через все это проходил.

Я тебе так скажу, Очень мало где видел, чтобы все "по полочкам раскладывали, пережевывали и в рот ложили". Но с первой работой повезло больше. Там как раз простая контора была, но был очень хороший шеф-технарь. Он все понял и уделял время. Хоть потом понял, что я вообще нулевой пришел. В отличии от тебя. Нужно подстраиваться под коллектив. Делать мало, но делать. Потом будешь делать чуть больше с большей увереностью. В начале я вообще думал, что только время у разработчиков забираю и ничего не делаю. Делал рутину за них. Тебе должно быть гораздо проще. Всего-то несколько месяцев поработал и уже расстроился. Я мучился больше года, чтобы хоть какую-то уверенность в знаниях получить.

Мне 33 и я самый молодой в моем отделе :)). А работаю я в Бельгии. Не смотрите на возраст. Только если уже решились, то надо быть последовательным и настойчивым.

Точно не могу проверить, но попробуйте такого вида запрос

SELECT u.id, u.name, u.affiliated_by FROM Users AS u 
LEFT JOIN Users AS u2 On u.id = u2.affiliated_by
ORDER BY u2.affiliated_by

(надо будет подстроить INNER/LEFT ну и сортировку)

Так сходу сложно определить, тем более протестировать.

Предлагаю дебажить построчно:

Начните с того, что убедитесь, что эта функция возвращает данные.

file_get_contents("https://api.vk.com/method/docs.getWallUploadServer?group_id={$group_id}&access_token={$rows[0]['token_group']}&v={$v}")

Далее убедитесь, что вот этот класс рабочий

new CURLFile(dirname(__FILE__)."/123.png")

Потом эту функцию проверьте, возвращает ли она что-то

curl($getWallUploadServer['response']['upload_url'], array("file1" => new CURLFile(dirname(__FILE__)."/123.png")));

Если есть вожможность, то выкладывайте сюда отладочные печати.

Вам надо вашу ViewModel подготовить перед выводом в темплейте так, чтобы там уже был выбранный selected элемент. Для этого у вас все данные есть.

Может так?

f2.treeView1.Nodes.Add(Array_Object_Link[i]);

Не надо строго на книге ориентироваться. Поставьте себе задачу и решайте ее. Идите на asp.net в разделе блогов смотрите как люди используют разные техники, методологии и т.п. Погуглите касаемо своей задачи. Как только нашли что-то чем-то похожее на свою задачу, начинайте изучать решение. Видите непонятный синтаксис, идете в msdn и смотрите, что вызывает ступор. Видите непонятную логику, идете в гугл и гуглите. Или идете на stackoverflow и спрашиваете там. Таким образом будет порядок в освоении. Если по книге будете идти, никуда не придете. Или придете, но через года 3 и более. Не эффективно это.

У вас, походу, это вообще бизнес логика. Нужен слой сервисов.

Соглашусь, что с гениями может быть сложно. Все зависит от того, захочет ли коллектив с таким гением работать, ну и от самого гения зависит. Этот не захотел. Не надо их выискивать. Это пустая трата времени. Ищите тех, кто максимально подходит на должность.

Если думаете, что избыточно, то не делайте, как он советует. Возможно, в вашей конкретной ситуации так и есть. А далее чутье или горький опыт подскажет где надо выделять обработку ошибок, а где нет.

А зачем вам это?

Попробуйте cross join

Вот тут посмотрите
смотреть

У меня на предыдущей работе был глава тестировщиков, которому 63. Он 30 лет проработал программистом. Сейчас нашел особо ненапряжную работу, для которой он чрезмерно квалифицирован, но его устраивает. К тому же, он новичков-тестировщиков натаскивает довольно хорошо. Особо в офисе не появлялся но "сложные/спорные" вопросы, помню, решались через него. Ах да, он там еще в роли UX-эксперта выступал.
По профессии, это действительно востребовано. И оплачивается нормально. Спокойно можете начинать)