Вот! Ваши рассуждения много проясняют и наталкивают на ряд полезных мыслей! Это хорошо. Кто прав, а кто не очень, ещё придется подразобраться, но всеже польза есть.
Меня вот ещё что волнует. Пока не совсем до конца продумал, как реализовать.
Допустим проект развивается. Есть пару контроллеров и хотелось бы часть функционала вынести в отдельные контроллеры. В результате контроллеров становится всё больше. Ну или как вариант, контроллеры оставляем как есть, но они разростаются в туеву хучу строк кода. Идем дальше. В проекте используется БД. Табличков всё больше и больше становится. Почти на каждую описывается сущность и реализуется DAO. В результате у нас много надо инжектить. Вот пример маинконтроллера:


и это не предел!
Так вот мне это не очень нравится. Да и контроллеров может быть много, я упомянал, и в каждом надо повторяться с инжекциями перечисленными выше. Хотелось бы эту инжекция и вообще реализацию логики вынести из контроллера в сервисы или в сервис. Что я должен делать? Я думаю описать класс с аннотацией @Service и заавтоваредить его в нужный мне контроллер. А уже в сервисе заавтоваредить нужные мне DAO. Правильно? В нутри (в сервисе) описать нужные мне методы, которые будут использоваться в контроллере. Какбы отвязываю DAO от контроллеров. Подозреваю, что с ростом проекта и это меня не будет удовлетворять.

Хорошо, тогда по теме. Про конфигурационные файлы. Всё, что я конфигурирую на данный момент, это в *.xml и в application.properties.
Значит в xml я описываю бины и их взаимосвязи, а в пропертях я описываю источник данных и логин-пароли. Сейчас будет глупый вопрос. Простите. Крутится приложение в TomCat. Задеплоено оно в виде war файла. Как мне менять эти конфигурации налету не раздеплоивая и не пересобирая проект?

забыл ник, всё верно! Ответственности начинают четко проявляться с ростом проекта. Собственно это мой первый проект java web, причем не реальный, а тестовый. Мало того! Так уж вышло, что изучение java, я начал практически сразу с javaEE. Вот пытаюсь усложнять и смотреть, в какую сторону надо менять проектирование, чтоб добится максимально гибкости (без фанатизма есно). Спасибо.

Просто, по началу, было не привычно, что в java любимая тема очень много файлов. Что не класс, то отдельный файл и т.д. Пусть даже класс на пару методов, но отдельным файлом. Причем, зачастую попадаются вообще интересные вещи/подходы! Вот допустим мне надо реализовать метод, который будет генерить префикс к файлу. В качестве префикса будет дата и время. Обычным, привычным способом, меня тянет реализовать это в виде процедуры, а в яве ненавязчиво намекают мол для этого нужно реализовать отдельный класс. Т.е. должен быть обьект, который ответственен за генерацию этого префикса. Это ломает обычное представление о программированиии. Приходится много чего переосмысливать.

Ещё вопрос. Как лучше/правильнее грузить бин? Через BeanFactory или через AplicationContext?

Остроумно, но всеже как лучше?
ApplicationContext context = new ClassPathXmlApplicationContext(...
context.getBean(...

или

BeanFactory factory = new XmlBeanFactory(new FileSystemResource(...
factory.getBean(...

В чем разница?

BlazkowiczЭто замена Dependency Injection на ServiceLocator
Странно. Один, из приведенных мной вариантов, описан там
http://cloud-cuckoo.com.ua/content/spring-dependency-injection-v-deistvii
именно как Dependency Injection.
Таким образом реализована слабая зависимость базового класса с рыцарем, а рыцаря с квестами. Можно конечно и на аннотациях реализовать, но по сути, я думаю, что смысл один и тотже.
Я не понял, что Вы имели ввиду.

Мое упрощенное понимание DI на этот момент:
Значит описываем мы конфигурации бинов в xml. Пишем какие быны нужны, откуда взять, как будут называться, как будут связаны между собой. На момент запуска приложения Spring создаст экземпляры обьектов в контейнере IoC. Далее, в нашем распоряжении есть ряд команд позволяющих получить экземпляр обьекта из контейнера. При этом, мы получаем экземпляр по имени и можем выполнять его методы описанные в интерфейсе. Т.е. использующий класс, по сути, изначально не знает кто именно и как будет реализовывать нужный ему методы. А вот контейнер как раз и инжектит эту зависимость в процессе выполнения.

XEugene, да да. BeanFactory находится/используется в Spring core containter для реализации Dependency Injection. Это какбэ фундоментально.. наверно, а остальное обвес.