Комментарии 14
Сегодня на Хабре прям соревнование промтов
ООП это про мусорные пакеты для плохого кода
Это точно... Выглядит первое время вполне ничего, но потом всё равно воняет и течёт, и надо его выбрасывать при первой же возможности)
В C#, для создания сервисов инстанцируемых в контексте исполнения HTTP запроса, используются Transient services
До меня в команде был разработчик, который добавил DbContext как Transient и поверх этого использовались репозитории. Контроллер содержал в среднем по 5+ репозиториев.
В результате, при каждом обращении к точке доступа вместо одного контекста создавалось куча. Видел даже метод, где в результате было создано 20 контекстов, 19 из которых были не нужны.
Мораль басни такова, что в контексте исполнения HTTP запроса использовать надо не жизненный цикл Transient, а свою голову на плечах.
Поэтому зарплата шарписта имеет вилку от 0 до 800 долларов за именно такого разработчика из вашей команды и от 3000 долларов за что-то более менее вменяемое
Из за этого, для малого и среднего бизнеса, лучше использовать именно NodeJS. А под базу на новых проектах лучше сразу взять какую-нибудь обертку типа supabase или appwrite, которая усреднит навык в среднем по палате, исключив неадекват
К слову, так как в данном случае жизненный цикл transient ограничен коллбеком, создать 20 контекстов будет как минимум неудобно технически
В SOLID для инъекции зависимостей выделена отдельная буква
В SOLID нет отдельной буквы для инъекции зависимостей, D - инверсия зависимостей, I - разделение интерфейсов.
https://en.wikipedia.org/wiki/Dependency_inversion_principle
Цитата:
All variable instantiation requires the implementation of a creational pattern such as the factory method or the factory pattern, or the use of a dependency-injection framework.
В этом месте википедии говорится о последствиях того что класс зависит от интерфейса, но это же не значит что инверсия зависимости неразрывно связана с инъекцией зависимости.
Мы же можем сделать инверсию зависимости и без Интерфейсов. И даже без внедрения чего-либо в конструктор или методы.
Можно сделать инверсию зависимости на модулях, если нам нужна какая-то зависимость внешняя, то мы можем определить свой промежуточный модуль и зависеть от него, а этот промежуточный модуль будет давать нам нужные услуги заимствуя эти услуги у внешнего модуля вендора. Это тоже будет инверсией зависимости.
В общем мне кажется инъекция зависимостей к SOLID все таки не относится.
А как это заставить делать джуна из института? И сколько на это уйдет времени, до дедлайна учить его структурировать код?
В данном случае, особенно если джун не говорит ни по русски, ни по английски, ему значительно проще дать ссылку на эту статью, для чего она и была создана. До ревью, по пунктам потребовать указать файлы, где применен каждый пункт
Вцелом я вашу идею понял, да согласен что этот вариант возможен просто дать ссылки и пусть разбирается с фреймворками с готовыми чеклистами.
Но есть и другой вариант. Вы пишите логику ядра, создаете продуманные классы, а джуны пишут клиентский код, создавая его из ваших классов которые вы сделали, так джуны будут находиться в песочнице и не сделают ничего плохого
Четыре пункта, как улучшить код Backend стажера