JDBC 실습 - 흐름 / SELECT [단순한 조회]

* DB 제어 의존 관계 설정 과정

1) dataSource 객체 생성

2) jdbcTemplate 객체는 dataSource 객체를 주입 (jdbcTemplate는 dataSource에 의존)

3) dao(repository) 객체는 jdbcTemplate 객체를 주입 (dao는 jdbcTemplate에 의존)

4) service 객체는 repository(dao) 객체를 주입 (service는 dao에 의존 - 쿼리문 처리 과정이 필요하기 때문)

5) controller 객체는 service 객체를 주입 (controller는 service에 의존)

 

* 각 객체의 역할

1) dataSource 객체 : 접속을 담당

2) jdbcTemplate 객체 : DB에 접근할 수 있는 통신기 역할 / 쿼리문을 쓰려면 필요 / dao한테 쿼리문 전달받은걸 dataSource에게 줌

3) dao 클래스 : 실제 데이터를 가져옴, 쿼리문 결과를 보내줌 jdbc에게 -> 한 번 호출에 하나의 쿼리문만 전송

4) service 클래스 : 하나의 동작 수행 -> but, 하나의 동작을 반드시 하나의 쿼리문으로 수행하지는 않음 / dao 다중 실행 역할

5) controller 클래스 :  dao를 통해 받아온 데이터와 뷰(jsp)를 연결

 

* dao <-> service의 차이 (확인 필요)

게시판 글을 조회한다고 하면, 조회수도 1 올라가야 하고(쿼리문 1번째 실행)

클릭한 글의 상세 정보를 DB에서 꺼내서 화면에 뿌려줘야(쿼리문 2번째 실행) 합니다.

즉, dao에서는 각각의 메서드가 하나씩 쿼리문을 실행하지만 service에서는 dao의 두 개의 메서드를 순차적으로 실행합니다.

---

* JDBC 실습 - 쿼리에 대한 하나의 결과값을 출력해주는 SELECT문 실행 (매개변수 X)

1) root-context.xml 파일에 dataSource 객체 / jdbcTemplate 객체 생성

   + 의존성 주입을 위해 컴포넌트 스캔도 설정해주기

 

 

2) VO 클래스 생성

- DAO에 넘겨줄, DAO가 호출할 때 필요한 DB의 정보를 담은 가방, 뷰에서 넘어온 자료가 담긴 가방

- 앞으로 생길 정보들을 담기 위해 저장소를 만들어 둔다고 생각

 

 

3) DAO 인터페이스 / 클래스 생성

- 실제 쿼리문이 작성되는 클래스

- 쿼리문을 jdbcTemplate 객체로 넘겨준다

- 쿼리문 결과값이 한 줄이므로, queryForObject() 메서드가 쓰인 것을 확인

 

4) Service 인터페이스 / 클래스

 

 

5) Controller 클래스 (흐름을 파악하는데 중요!!)

 

# 소스의 흐름

- 사용자로부터 hr/count 라는 입력이 들어옴

- empService의 getEmpCount 메서드 호출 -> Service 클래스로 이동

- Service 클래스의 getEmpCount를 호출하려고 보니, 사실은 DAO에 있던 메서드였음 -> DAO 클래스로 이동

- DAO 클래스의 getEmpCount를 호출하니, 리턴값을 jdbcTemplate로 보내버림 -> jdbcTemplate 객체로 이동

- jdbcTemplate 객체로 이동하고 보니, 알고보니 얘도 DataSource를 가지고 있었음 -> DataSource로 이동

- DB 처리를 마치고 결국 돌고 돌아 최종 값 count 변수를 "count" 이름으로 저장하기 위해 -> 다시 Controller 클래스로 다시 돌아옴

- 컨트롤러는 뷰 리졸버와 함께 문자열을 조합하여 hr/count.jsp 파일을 브라우저에 전달해줌

--> 결국 컨트롤러는 시작부터 끝까지 책임을 다하는 착한 클래스

--> 즉, 흐름을 순서대로 나열하자면

Controller -> Service -> DAO -> jdbcTemplate -> DataSource -> DB -> Controller(+ViewResolver) -> jsp -> 브라우저

 

6) jsp 파일 생성 및 브라우저에서의 호출