목차
알고리즘
1. k번째 수
프로그래머스_k번째 수
풀이
Arrays.copyOfRang을 활용한 코드
priorityQueue를 활용한 코드
토비의 스프링
1. 복습
복습 리스트
Toby3 166p ~ 213p까지 유튜브 강의
1.
StatementStrategy interface정의 – 222p
2.
StatementStrategy interface를 구현한 DeleteAllStrategy() 구현 – 222p
3.
UserDao의 deleteAll()에 적용 – 225p
4.
deleteAll()에서 jdbcContextWithStatementStrategy분리 – 225p
5.
deleteAll()에서 jdbcContextWithStatementStrategy(StatementStrategy stmt) 호출하게 적용 – 225p
6.
AddStrategy() 구현 – 227p
7.
UserDao의 add()에 적용 – 228p
8.
AddStrategy까지 적용된 소스코드
docker 내려가는분--비밀번호 유출에 의한 해킹 가능성
// 특정 컨테이너가 종료된 경우 로그 보기
docker container ls -a | grep mysql
마지막 50줄 로그 보기
docker logs --tail 50 <container_id>
Plain Text
복사
2. DataSource 인터페이스 적용
DataSource의 개념
•
자바 프로그램에서 connection 객체를 얻는 것은 시간이 걸린다.
•
일정량의 connection 객체를 미리 만들어 저장하고, 요청 시 꺼내 사용한다.
•
위와 같은 과정으로 구현하면 속도와 퍼포먼스가 좋아진다.
•
connection pool을 관리하고, connection 객체를 pool에서 꺼내 사용했다 반납하는 이러한 과정을 DataSource가 한다.
DataSource를 활용한 UserDaoFactory 리팩토링
UserDaoFctory 리팩토링 코드
DI할 때 final을 사용하는 이유
•
final이란 무엇인가?
◦
한번 초기화 되면 바꿀 수 없는 것
◦
private final DataSource dataSource;
◦
final로 선언한 변수는 재할당을 할 수 없다.
•
final을 사용할 때 이점
1.
변화를 고려하지 않아도 된다.
2.
변경을 고려하지 않기 때문에 변경에 필요한 메모리 할당이 필요없다. - memory를 절약
3.
Di하고나서 DataSource가 바뀌는 경우 - 무슨일이 일어날지 예측이 안된다.
•
final을 쓰는 이유
1.
Spring에서 DI되었다면 이미 Factory에서 조립이 끝난 상태이므로 변화하지 않는게 좋다.
2.
변화하지 않는게 좋으므로 final로 쓰는게 좋다. 왜냐하면 메모리 사용에 유리하고 신뢰성 있기 때문
3.
이후 SpringBoot에서 @Autowired하는 부분이 final로 대체하는 것을 권장하게 바뀜.
3. 익명 클래스 도입
deleteAll, add 메소드에서 익명 클래스를 사용하는 이유
StatementStrategy Interface 구현체인 DeleteAllStrategy와, AddStrategy를 쓰는 곳은 UserDao의 각 deleteAll, add 메소드 한곳이므로 굳이 class를 새로 만들 필요가 없다.
deleteAll, add 메소드 리팩토링
jdbcContextWithStatementStrategy 를 사용할 때는 StatementStrategy 인터페이스 구현체를 넘겨주어야 한다.
deleteAll 메소드 코드
add 메소드 코드
4. JdbcContext로 분리
UserDao의 jdbcContextWithStatementStrategy를 클래스로 분리하는 이유
jdbcContextWithStatementStrategy는 다른 Dao에서도 사용할 수 있다. (ex. HospitalDao) 그래서 다른 Dao에서도 쓰기 위해 UserDao에서 분리 한다.
JdbcContext분리
JdbcContext 클래스 코드
UserDao에 JdbcContext를 의존하게 리팩토링
의존관계가 UserDao가 JdbcContext의존하게 변경됨
new JdbcContext(dataSource);
책에서는 위 구간을 set을 활용해 구현했지만 이 방식은 xml 설정 방식이다.
지금은 xml 설정 방식을 잘 사용하지 않기 때문에 생성자로 구현한다.
UserDao 리팩토링 코드
지금까지 적용했던 Strategy 패턴들
JdbcContext와 DataSource의 관계 설정을 Constructor에서 한 이유
5. Template Callback 적용
callback
add함수를 호출하면 jdbcContext.workWithStatementStrategy함수가 호출되고
workWithStatementStrategy 함수는 StatementStrategy 함수를 호출 그리고 PreparedStatement를 반환받고 돌아오고 workeWithStatementStrategy함수는 종료 다시 add함수로 돌아온다.
executeSql 메소드
executeSql 메소드 코드
deleteAll 메소드 코드
6. Jdbc Template 적용
JDBC란?
DB에 접근할 수있도록 Java에서 제공하는 API
Plain JDBC의 문제점
•
쿼리를 실행하기 전과 후에 많은 코드를 작성해야한다. (연결생성, 명령문 etc..)
•
예외처리코드와 트랜잭션 처리등에 시간과 자원이 소모된다.
◦
jdbc에서 발생하는 에러는 Runtime Exception이다. 따라서 모두 예외처리를 해줘야한다.
•
이러한 문제점을 보완하기 위해 spring JDBC이다.
Spring JDBC란?
JDBC의 단점을 보완하여 더 편리한 기능을 제공
Spring JDBC가 하는 일
•
Connection 열기와 닫기
•
Statement 준비와 닫기
•
Statement 실행
•
ResultSet Loop처리
•
Exception 처리와 반환
•
Transaction 처리
Spring JDBC에서 개발자가 할 일
•
datasource 설정
•
sql문 작성
•
결과 처리
JDBC Template이란?
Spring JDBC 접근 방법 중 하나로, 내부적으로 Plain JDBC API를 사용하지만 위와 같은 문제점을 해결한 Spring에서 제공하는 클래스
JDBC Templete이 제공하는 기능
•
실행 : Insert나 Update같이 DB의 데이터에 변경이 일어나는 쿼리를 수행하는 작업
•
조회 : Select를 이용해 데이터를 조회하는 작업
•
배치 : 여러 개의 쿼리를 한 번에 수행해야 하는 작업
•
jdbc template을 사용하면 커넥션 연결/종료와같은 세부적인 작업을 개발자가 직접 처리하지 않아도 되게된다.
JPA란?
JDBC Template보다 더 추상적인 클래스
JdbcTemplate 활용
UserDao 리팩토링 코드
UserDaoTest 코드
7. 복습 유튜브 비디오
1.
DataSource적용 183p
2.
deleteAll()에 익명 클래스 적용 233p
3.
add()에 익명 클래스 적용 232p
4.
JdbcContext 클래스로 분리 234p
