티스토리 뷰
예전에는 책을 읽어도 제대로 이해가 되지 않아서, 그냥 가볍게 읽고 넘어 갔던 부분이었습니다. 그러나 지금 개발을 제대로 하려고 노력하며 다시 책을 꺼내 읽어보니.... 아주 조금은?? 이해가 되는 것 같습니다. :)
DI(Dependency Injection)에 대한 내용은 최범균님의 '초보 웹 개발자를 위한 스프링4 프로그래밍 입문' 책을 읽고 제가 이해한 내용을 적었습니다. 문제가 될 시 삭제 하겠습니다.
1) 의존이란?
사진을 보면 MemberRegisterService 클래스는 DB 처리를 위해 MemberDao 클래스의 메서드를 사용합니다. 이렇게 한 클래스가 다른 클래스의 메서드를 실행할 때, 이를 의존한다고 표현합니다. 위 코드는 MemberRegisterService 클래스가 MemberDao클래스에 의존한다고 표현할 수 있습니다.
**) 의존은 변경에 의해 영향을 받는 관계를 의미합니다. MemberDao insert() 메서드의 이름을 insertMember()라고 변경하면 이 메서드를 사용하는 MemberRegisterService클래스의 소스코드도 함께 변경되며 이렇게 변경에 따른 영향이 전파되는 관계를 '의존'한다고 표현합니다.
위와 같이 클래스 내부에서 직접 의존 객체를 생성하는 것이 쉽기는 하지만, 유지보수 관점에서 문제를 유발할 수 있습니다.
2) DI(Dependency Injection)
DI는 Dependency Injection의 약자로, 우리말로는 의존 주입이라고 번역합니다.
DI 의존주입은 의존하는 객체를 위 사진과 같이 직접 생성하지 않고 의존 객체를 전달받는 방식을 사용합니다.
XML과 Java로 Bean을 동록하여 Constructor나 Setter 또는 @Autowired 통해 객체를 전달할 수 있습니다.
DI를 사용하는 장점은 변경의 유연함입니다. 동일한 상황에서 DI를 사용하면 수정할 코드가 줄어듭니다. 아래 코드와과 같이 모든 클래스에 객체를 생성하게 될시, 처음에는 불편함을 느끼지 않겠지만.. 나중에 MemberDao가 Cached 기능을 사용할 일이 생겨서 MemberDao를 상속받는 CachedMemberDao로 바뀌게 되면 객체를 생성하는 모든 클래스에 가서 소스를 일일히 찾아서 수정해야 합니다.
//변경 전
public class MemberRegisterService{
private MemberDao memberDao = new MemberDao();
}
//변경후
public class MemberRegisterService{
private MemberDao memberDao = new CachedMemberDao();
}
그런데 DI를 사용하게 되면 아래 코드와 같이 실제 객체를 생성하는 한 곳의 소스를 수정하면 되기 때문에 번거로움과 관리 측면에서 좋습니다.
즉 코드의 결합도를 낮출 수 있습니다.
@Configuration
public class JavaConfig {
@Bean
public CachedMemberDao memberDao(){
return new CachedMemberDao();
}
}
***) 예를 들기 위해 위와 같이 JavaConfig에 Bean으로 선언을 했습니다. 사실 그냥 CachedMemberDao.class에 @Component나 @Repository 에노테이션을 선언하여 Bean으로 만들고 실제 사용하는 서비스에서 @Autowired로 주입받으면 간단합니다 ㅎㅎ
@Autowired
private MemberDao memberDao;
@Override
public void run(ApplicationArguments args) throws Exception {
Member member = memberDao.selectByEmail(req.getEmail());
}
그리고 위 코드와 같이 실제 사용하는 서비스에서는 @Autowired나 Constructor, Setter 방식 중 한가지를 선택해 객체를 주입받으면 됩니다. 저는 @Autowired로 주입 받았습니다. ㅎㅎ
DI Look up 방식은 위에 설명한대로 XML또는 Java 설정을 통해 Constructor, Setter, @Autowired 중 한 방식을 통해 객체를 주입 받습니다.
사실 요즘은 XML 방식을 잘 사용하지 않습니다. 오래전에 시스템이 구축된 곳은 XML방식을 사용하지만, Bean 설정을 잘못했을 때 에러를 잡아내기 쉽지 않고 가독성과 설정의 불편함이 있어서 Java를 통해 Bean을 만드는 추세 입니다. 제가 다니고 있는 회사에서도 JavaConfig와 @Autowired 방식을 통해 DI Look up 을 하고 있습니다.
실제로 내부 객체 같은 경우는 @Component, @Configuration, @Repository, @Service, @Controller 등을 통해 Bean 설정이 가능하고 간단하게 주입 받을 수 있습니다.
'jvm언어관련 > Spring(SpringBoot)' 카테고리의 다른 글
간단한 springboot error 처리 (0) | 2019.02.22 |
---|---|
[책]자바 기반의 마이크로서비스 이해와 아키텍처 구축하기 (0) | 2019.02.18 |
EhCache 사용(Spring+Maven) (0) | 2019.02.11 |
AsyncRestTemplate 사용하기 (0) | 2019.01.28 |
spring boot 로컬환경에서 https 사용하기 (0) | 2019.01.01 |
- Total
- Today
- Yesterday
- 뱅셀 유전자
- spring-boot-starter-data-redis
- update query set multiple
- effectivejava
- update query mutiple row
- 이펙티브자바
- 슬랙 /
- multiple row update
- update query
- visual studio code
- 이것이 자바다
- 싱글턴
- update set multiple
- 그레이들
- 뱅크샐러드
- springboot https
- Slack
- update set multi
- 몽고DB 완벽가이드
- 슬랙봇
- gradle
- vue.js
- 다중 업데이트
- 업데이트 쿼리
- SpringBoot
- java
- update query multi row
- MSSQL
- 슬랙
- 뱅크샐러드 유전자
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 | 31 |