Какие ключевые архитектурные принципы Spring?

Так, слушай, вот эти все умники с их "фундаментальными принципами" — они же, блядь, как будто на латыни говорят. А на самом деле всё просто, как три копейки. Щас разжуем.

Вот смотри, Spring — это такой хитрожопый фреймворк, который тебе жизнь облегчает, но сначала надо понять, на какой, блядь, магии он работает.

1. Инверсия управления (IoC) Представь, ты раньше сам, как обдолбанный, бегал по магазинам за компонентами для своего кода: "Так, мне нужен репозиторий, щас создам... а, для него нужен датасорс, щас создам... ой, а для датасорса нужны проперти, щас их загружу..." Пиздец, а не жизнь.

А теперь — инверсия. Это когда ты говоришь: "Слушай, Spring, я хочу UserService. А что ему нужно для работы — это уже твои, блядь, проблемы". И контейнер Spring, как заправский диджей, сам всё миксует и тебе готовый, настроенный объект подсовывает. Управление перевернулось — не ты за фреймворком бегаешь, а он тебе всё приносит. Красота, ёпта!

2. Внедрение зависимостей (DI) Это и есть конкретный способ, как Spring свою инверсию реализует. Ты не создаешь зависимости внутри класса, а говоришь: "Я хочу, чтобы мне их впендюрили снаружи". Как будто тебе в конструктор или прямо в поле шприцем вводят нужную хуйню.

• Внедрение через конструктор (самое правильное и мужицкое):

  @Service
  public class UserService {
      private final UserRepository repository;
  
      // Аннотацию @Autowired можно уже не ставить, Spring и так умный
      public UserService(UserRepository repository) {
          this.repository = repository; // Вот, получил репозиторий и сразу привинтил
      }
  }

  Почему предпочтительно? Да потому что объект создается сразу в рабочем состоянии, все зависимости видны как на ладони, и тестить его — одно удовольствие. final поле — это вообще песня, никакой мути после создания.

• Внедрение через поле или сеттер: Это уже для ленивых или для легаси кода. Типа, наставил @Autowired над полями и думаешь, что красавчик. А на самом деле код становится хрупким, как яичко, и тестировать его — тот ещё геморрой. Избегай, если можешь.

3. Аспектно-ориентированное программирование (AOP) Вот это, блядь, магия чистой воды! Есть же такая сквозная хуйня, которая везде торчит: логирование, транзакции, замеры времени. Писать это в каждом методе — это ж застрелиться можно.

Так вот, AOP позволяет выдрать эту общую логику в отдельный модуль — аспект. И потом сказать Spring: "Смотри, везде, где есть методы с @Transactional, оберни их в мою транзакционную обвязку". И он обернет! Как будто невидимая сила лезет в твой код и делает ему магию. Со стороны выглядит как ебалай волшебства, но работает-то, сука, как часы.

4. Модульность Spring — он не монолитный здоровяк. Он как конструктор: есть ядро (Core) — основа основ. Есть Spring MVC — для веба. Есть Data — для работы с базами. Security — для охраны твоего приложения от пидорасов. Boot — вообще отдельная песня, чтобы всё это быстро запускать. Берёшь только то, что нужно. Не хочешь веб — не тащи за собой всю библиотеку MVC. Удобно, ёпта!

5. Конвенция вместо конфигурации Раньше, сука, чтобы описать бины, нужно было писать XML-файлы на триста строк, где каждая запятая могла отправить тебя в дебаг на полдня. Пиздец и ужас.

А теперь — аннотации. Написал над классом @Service — всё, Spring уже понял, что это сервисный бин. Над полем @Autowired — понял, что туда надо что-то инжектнуть. Конфигурации минимум, а фреймворк по умолчанию делает всё как надо. Жить стало проще, ядрёна вошь!

6. Простота тестирования А вот это, пожалуй, самый охуенный принцип. Раз твои классы — это простые POJO (Plain Old Java Objects), которые не дергают напрямую какие-то сервисы, а ждут, когда им зависимости впрыснут, то их тестировать — одно удовольствие. Хочешь протестить UserService? Да пожалуйста! Создаёшь в тесте мок-объект для UserRepository (с помощью Mockito, например) и передаёшь его в конструктор сервиса. Никаких поднятых контекстов, никаких реальных баз данных. Чисто, изолированно, быстро. Мечта, а не тестирование.

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