IoC - это, в основном, хорошая вещь в языке Java, потому что, когда большинство приложений начинают расти, и вы не разрабатываете для модульности / слабой связи, вы получаете большую кучу взаимосвязанных классов без каких-либо разумных границ.
Для начала, Spring и другие IoC / DI-структуры заставляют задуматься о модульности с самого начала. Это очень важно, потому что если ваш код хорошо модульный / слабосвязанный, вы в конечном итоге создаете компоненты и многократно используете их, что приводит к улучшению модульного тестирования (если вы все равно проводите модульное тестирование).
Если я хочу написать DAO, я могу заранее определить его интерфейс:
interface IPersonDao {
List<Person> getPersonsByTeam(String teamName);
}
тогда я могу просто призвать к реализации этого интерфейса из любого места в src, где "применяется" Spring. Предположим, мне это нужно на уровне сервиса:
class MyService {
@Autowired
IPersonDao svc;
}
или в тестовом классе:
class TestPersonDao {
@Autowired
IPersonDao svc;
@Test
void testGetPersons(){
List<Person> persons = svc.getPersonsByTeam("billing");
Assert.assertDataSet(persons, "billing.xml");
}
}
Кроме того, моя реализация Dao может скрыть сложности доступа к данным, не вмешиваясь в контракт Dao. Если мне требуется сеанс гибернации или диспетчер персистентности, я просто заявляю, что:
class JpaPersonDao implements IPersonDao {
@PersistenceContext
EntityManager em;
List<Person> getPersonsByTeam(String tm) {
em.createQuery("...");
}
}
Компонентация классов требует реестра для связи сотрудничающих bean-компонентов. Это может быть разработано вручную, но уже есть структуры DI, которые делают это. Кроме того, у Spring есть много других вещей, таких как трансляция исключений, поддержка аспектного программирования, фреймворки mvc, фреймворки портлетов, интеграция с hibernate, jpa и / или другими стеками БД, которые, конечно, хорошо интегрируются с Spring IoC.