프레임워크의 비침투성 (DL과 DI)

[sihyung92]

왜 DL보다 DI를 사용할까요~? 케빈의 1장2주차 리뷰에 나온 좋은 내용 공유합니다!
링크

프레임워크의 비침투성

우리가 이번 주차에 학습한 내용 중에는 의존관계 검색이라는 방식이 있었는데요.

UserDao.java

public UserDao() {
    AnnotationConfigApplicationContext context = new AnnotationConfigApplicationContext(DaoFactory.class);
    this.connectionMaker = context.getBean("connectionMaker", ConnectionMaker.class);
}

• 주입을 받는 방식이 아니라, 자신이 사용할 의존 객체를 컨테이너에게 직접 요청하여 가져오는 방식.
  • 의존 객체의 내부 정보(의존성, 구현 클래스) 등은 알지 못한다. 즉, 자신이 필요로 하는 객체를 능동적으로 찾으나, 해당 Bean의 의존 관계 설정과 생성 및 구현체 등의 로직은 여전히 외부 컨테이너에게 위임한 상태이다.
• UserDao 클래스 코드에 관심사가 분리되지 않아 대부분의 경우 DI가 더 낫다.
  • DI를 받을 수 없는 엔트리 포인트 등에서나 사용.

Spring Core Technologies docs에는 다음과 같이 명시되어 있습니다.

You can then use getBean to retrieve instances of your beans. The ApplicationContext interface has a few other methods for retrieving beans, but, ideally, your application code should never use them. Indeed, your application code should have no calls to the getBean() method at all and thus have no dependency on Spring APIs at all.

• 이상적으로는 getBean()을 사용하지 말자. 어플리케이션 코드가 Spring API와의 의존성이 생긴다.
  • 현재 우리는 실습 때문에 어플리케이션의 엔트리 포인트에서는 어쩔 수 없이 getBean()을 호출하지만, 이 마저도 SpringBoot에서는 쓸 일이 거의 없음.
  • Spring 관련 Configuration에서는 사용할수 있을지 몰라도, 어플리케이션의 핵심적인 부분(도메인 모델 등)에서 사용하게 된다면?
  • 프레임워크의 코드가 침투하게 되어 추후 다른 프레임워크로의 마이그레이션 등 유지보수나 테스트가 어려워진다.

[sihyung92]

지금은 저희가 스프링의 쩔을 받지만 프레임워크에 대한 의존성은 항상 유의해야한다고 생각합니다~~! 새롭게 떠오르는 웹어플리케이션 프레임워크가 두둥 등장했을 때 모듈화한 도메인 코드를 연결만 해서 돌릴 수 있는 개발자가 되고 싶습니당.. ^_^

[xlffm3]

비슷하게 Spring 4.2이전에는 이벤트를 발생시킴에 있어서, ApplicationEvent 클래스를 상속받아야했는데요.
4.2 이후에는 @eventlistener 애너테이션의 도입으로 인해 특정 클래스를 상속받아야하는 제약이 사라졌어요.
Spring이 비침투적이라고는 하지만 침투적인 부분들은 여전히 존재하는것같고, 그걸 계속 개선해나가는것같아요!
그러니 개발자도 사용할때 유념하면 좋을것같고...

그런데 Spring Data JPA는 침투적인가 아닌가에 대해 궁금해졌는데요.

ㅎㅎ 재미있는 주제?!

[Be-poz]

주류의 프레임워크가 이렇게나 침투적이니 나중에 다른 프레임워크가 등장했을 때에 변경하기가 어려울 것이다! 라고 말할 수는 있을 것 같아요.
하지만, 개인적인 생각으로는 프레임워크를 교체하게 되면 결국에는 비용이 들어가기 마련이고 아무리 침투적이라고 하더라도 1부터 100까지 다 뒤덮혀있는 것도 아닐텐데 그 정도는 수용할만하지 않나? 라는 생각이드네요.

[xlffm3]

One of the central tenets of the Spring Framework is that of non-invasiveness. This is the idea that you should not be forced to introduce framework-specific classes and interfaces into your business or domain model.

However, in some places, the Spring Framework does give you the option to introduce Spring Framework-specific dependencies into your codebase.

The rationale in giving you such options is because, in certain scenarios, it might be just plain easier to read or code some specific piece of functionality in such a way. However, the Spring Framework (almost) always offers you the choice: You have the freedom to make an informed decision as to which option best suits your particular use case or scenario.

저도 동의합니다