75일 - DI, @Autowired로 결합하는 과정

// MyBatis 쓰면서 얻는 장점 -> 급격한 코딩량의 다이어트

- 해석해서 @ 붙어있는 녀석의 반환타입을 보고 알아서 ~ 해줌 

-> 반환타입에(<Notice>) 맞게 getList() 함수 구현해서 바구니(IoC 컨테이너)에 담아놓는다. 끝

 

/ 정말 한 줄만 이렇게 쓰면 되는거. 

 

* 사용법 *

- 꺼내놓기만 하면 되는데, 이때 DI 가 필요하다는 것

---

injection 작업을 해보자.

각각 의미를 두어서 사용하는게 Better (다 @Component라고 하지 말고) 

 

//

 

xml vs annotation하는거 (@)

 

A 클래스, B 클래스 있고, B를 대체하는 B2를 만든다고 해보자. (개선된 버전)

- xml은 a, b, a+b, ... 그리고 B2 설정을 위한 b2까지. 

-> 굳이 b2 설정을 또 해야하나? b를 가지고 어떻게 할 수는 없을까? 

 

설정으로 해버리면 됨! 

 

annotation 달고 있는 놈 하나면 됨.

ex) 오늘의 셰프가 'a'인지 'b'인지를 원래는 xml에 오늘은 a야 ~ 오늘은 b야~ 라고 알려줬었는데,

     이제는 그냥 셰프가 명찰(@annotation)을 달게 한 것. 그러면 알아서! a가 명찰 달고 있으면 a가 셰프구나~ b가 명찰 달고 있으면 b구나~ 하고 알 수 있다는 이야기

 

//

 

NoticDao를 어떻게 꺼내올까. 

 

NoticeController

 

@Autowired

"네가 알아서 내게 맞는 (내 인터페이스는 NoticeDao)걸 IoC 컨테이너에서 꺼내줄래?

- 객체들 담겨있는 컨테이너에서 NoticeDao를 구현한게 있으면 가지고 오라는 것

1) 스프링이 일어남 

2) @Mapper 담으면서 동시에 MyBatis도 @Mapper를 읽으면서 담음

3) 두 개를 다 담으면서 수 - 많은 설정들을 읽음

4) 톰캣 실행 

-> 양쪽 다 담겨져 있음

 

단순히 담겨져 있는게 아니라 조립까지 해줌

1) /notice/list 요청 오면 

2) noticeDao 통해서 서비스 받을 수 있다. 

-> noticeDao.getList(); 

테스트 for 화면출력

27 해줌으로서 -> 32. 뷰 페이지 찾는게 아니라 '그냥 이게 view'다 라고 해줄 수 있는거지 ~ 

 

cf) @Autowired 

- (김영한 인강) 컨트롤러랑 리파지토리랑 연결해주는 역할

- 

 

이렇게 나옴! 

- 넘넘 신기해해야함. 쿼리식 하나 적어준 것 밖에 없는 것 같은데 데이터가 막 나와 막 나와... 

 

//

 

@ResponseBody 지우고 정상적으로 해보자

 

//

 

근데 이렇게 Dao랑 컨트롤러랑 직접 연결해주는건 잘못된 것

-> 17번째줄 삭제

 

NoticeService 구현해주는! 클래스 하나 추가하자

 

// setter만 추가

@autowired 

- 생성자에서도 가능 setter뿐만 아니라

 

cf) 객체 결합 방법

1) 일체형 2) 분리형

a.setB(B b)도 가능하고 이것도 가능하고 

 

+ 또 다른 방법 - field injection

-> rtti?를 보는건 private, public 다 나옴.

    거기에다가 대입 가능..?

 

//

@autowired

1) 생성자 인젝션

2) setter 인젝션

3) 필드 인젝션 

-> 하자마자 할 수 있는 처리 로직을 가지고 있는 이게 good & 가장 간단

 

우선순위! 

1. 하자마자는 필드 인젝션

- 이건 오버로드밖에 

2. 초기화할 일이 있다. 생성자 인젝션

- ex) 내가 디폴트 값을 직접 해주고 싶을 때 

3. 예외적으로 setter

 

//

 

NoticeController 와보자.

 

박씨 가문인데 굳이 박씨라고 말할 필요가 없음.

ex) NoticeService noticeService 아니라, 그냥 뒤에 service로만 써도 된다는

 

@Autrowired

-> 컨테이너에서 찾아서 연결시켜준 것

- 근데 null 오류 날 것

이유 : 서비스를 컨테이너(콩자루)에 넣지 않아서. 

 

근데 인터페이스는 객체화 할 수 없기에 

- 구현체에다가 @ 

다 콩보다리에 올라감 (누가 먼저랄거 없이)

 

부품부터 결합해서 더 큰 제품이 만들어지는거니까 

-> 가장 작은 부품인거, 맨 왼쪽부터 그래도 가장 먼저 올라감

// 

 

adminNoticeController로 가자

L: 이전 R: @Autowired 사용한거

은정님거

service.getList(); 

화면 봐야함

 

process 훓어보기

(이건 잘 안보여서 다시 캡쳐) 

Controller <- Service <- Dao 

(1) NoticeDao 통해서 SQL 연결시켜 함수 이용하게 하고 

(2) (1)을 통해서 비즈니스 서비스 만들고 (ex - hitUp, likeUp...) 

(3) (2)를 통해 Controller 에서 M, V 역할을 수행하고

 

 

 

//

 

각각 '서로 특화된 것들'로 생각해야

 <- 맨 끝에 R : 데이터 조작 (레코드 단위임!(한 줄 한 줄) '모든 레코드는 이거 update 하나로 되는구나~') 

ex) hit든, 작성자든, 뭐든 update면 컬럼별로 만들 필요 없음. 그냥 update 하나면 되는 것

 

// 

 

insert, edit 

파라미터들 넘겨받는거 어떻게 하는지는 내일

 

스프링의 이 3가지 개념을 충~분히 익숙하게 하기!!! 

1) 스트링 MVC

2) 객체 결합해주는 DI 기능

3) Mybatis의 멋진 기능

 

 

//

cf) @mapper 뜻 

-> SQL 매핑해준다는 것

즉, 콩자루에 "매핑 정보 여기 있어~~!" 하는 것

 

JDBCNoticeDao 파일은 삭제해도 되는 것

- 직접 구현하면 채우며 했겠지만, MyBatis 활용함으로서 안해줘도 되는 것 :)

- 그냥 NoticeDao에 '최소한의' 쿼리만 만들어주면 알아서 해준다는 것~!