Java & Spring
-
3장) 3.4 컨텍스트와 DI ~ 3.5 템플릿과 콜백Java & Spring/토비의 스프링 3.1 2021. 6. 11. 16:44
3장 템플릿 3.4 컨텍스트와 DI JdbcContext의 분리 전략 패턴 구조 UserDao의 메소드가 클라이언트 익명 내부 클래스로 만들어진 것이 개별적인 전략 jdbcContextWithStatementStrategy 메소드가 Context JDBC의 일반적인 작업 흐름을 가지고 있는 컨텍스는 다른 DAO에서도 사용 가능 ~> 분리 시켜보자 클래스 분리 JdbcContext가 DataSource에 의존 ~> DataSource 타입 빈을 DI 받게 변경 생성자를 통해 DataSource 주입 빈 의존관계 변경 클래스 분리로 인해 UserDao는 JdbcContext에 의존하고 있지만, JdbcContext는 구체 클래스 스프링 DI는 인터페이스를 사이에 두고 의존 클래스를 바꿔 사용하는게 목적 하지..
-
3장) 3.1 다시 보는 초난감 DAO ~ 3.3 JDBC 전략 패턴의 최적화Java & Spring/토비의 스프링 3.1 2021. 6. 11. 16:43
3장 템플릿 개방 폐쇄 원칙 확장에는 자유롭게 열려 있고 변경에는 굳게 닫혀 있다. 3.1 다시 보는 초난감 DAO 2장에서 Test와 관련해서 DB 연결과 관련된 여러 개선 작업을 진행했지만, 예외상황 처리 부분이 미흡하다. 이를 개선해보자. 예외처리 기능을 갖춘 DAO JDBC는 예외가 발생한 경우에도 리소스를 반드시 반환해야함 Connection Pool에서 리소스를 받아와 사용하기 때문에, 반환을 제대로 해주지 않은 리소스가 많아져서 connection pool에서 리소스가 부족하다는 치명적인 Exception이 발생할 수 있음 public void deleteAll() throws SQLException { try (Connection c = dataSource.getConnection(); P..
-
2.4 스프링 테스트 적용 ~ 2.6 정리Java & Spring/토비의 스프링 3.1 2021. 6. 3. 14:32
2장 테스트 2.4 스프링 테스트 적용 앞서 작성한 테스트 코드에서 @Before(Junit5는 BeforeEach)로 인해 Application Context가 테스트 메소드 개수만큼 생성되는 문제점이 존재 Application Context 생성에는 많은 시간과 자원이 소모 테스트 전체가 공유하는 오브젝트로 수정 빈은 싱글톤으로 만들었기 때문에 무상태성 UserDao 빈을 가져다 메소드를 사용한다고 해서 상태가 바뀌지 않음 @Before(Junit5 -> @BeforeEach)를 @BeforeClass(Junit5 -> @BeforeAll)로 수정 테스트 클래스 전체에 걸쳐 딱 한번만 실행 테스트를 위한 Application Context 관리 Junit을 이용하는 테스트 컨텍스트 프레임워크를 제공 ..
-
2장) 2.3 개발자를 위한 테스팅 프레임워크 JUnitJava & Spring/토비의 스프링 3.1 2021. 6. 1. 13:47
2장 테스트 2.3 개발자를 위한 테스팅 프레임워크 JUnit 스프링 프레임워크도 JUnit을 이용해 테스트를 통해 개발됨 테스트 없이는 스프링도 의미 없음 빌드 툴 ANT, Maven, Gradle과 같은 빌드 툴과 스크립트를 사용한다면 ~> 빌드 툴에서 제공하는 Junit 플러그인이나 태스크를 이용해 JUnit 테스트를 실행 테스트 결과의 일관성 DB 서버가 다운되거나 네트워크 장애 등 외부 상태에 따라 테스트가 성공하기도 실패하기도 한다면 좋지 못한 테스트이다. 또한, 테스트를 마친 후, 수행하기 이전으로 DB의 상태를 돌려야 함 동일한 결과를 보장하는 테스트 예시의 테스트를 시작하기 전에 기존의 데이터를 항상 지우고 시작하게 설정하면, 해당 add를 하는 메소드에서, 항상 같은 결과 값을 리턴한다..
-
2장) 2.1 USERDAOTEST 다시보기 ~ 2.2 USERDAOTEST 개선Java & Spring/토비의 스프링 3.1 2021. 5. 27. 13:51
2장 테스트 객체지향 기술과 더불어 하나의 도구로 스프링이 강조하고 가치를 둔다. 2.1 UserDaoTest 다시보기 테스트의 유용성 테스트란, 예상하고 의도했던 대로 코드가 정확히 동작하는지를 확인 ~> 확신 결과가 원하는 대로 나오지 않는 경우 ~> 코드나 설계에 결함 확인 웹을 통한 DAO 테스트 방법의 문제점 문제점 DAO 뿐만 아니라 서비스, 컨트롤러, 뷰 등 모든 레이어 기능을 만든 후, 테스트가 가능 테스트에 실패하면, 어디에서 문제가 발생했는지 찾아야하는 수고가 필요 단위 테스트 테스트는 가능하면 작은 단위로 쪼개서 집중해서 할 수 있어야한다. 관심이 다르다면, 테스트할 대상을 분리하고 집중해서 접근한다 작은 단위 코드에 대한 테스트가 단위 테스트이다. 정해진 범위나 단위가 정해지지는 않..
-
1장) 1.8 XML을 이용한 설정 ~ 1.9 정리Java & Spring/토비의 스프링 3.1 2021. 5. 27. 13:50
1장 오브젝트와 의존관계 1.8 XML을 이용한 설정 장점 별도의 빌드 작업이 필요 없다 환경이 달라져서 오브젝트의 관계가 바뀌는 경우, 빠르게 변경사항 반영 가능 XML 설정 DI 정보가 담긴 XML 파일은 를 루트 엘리먼트로 사용 @Configuration과 @Bean이 붙은 자바 클래스로 만든 설정과 내용이 동일 @Bean의 DI 정보 3가지 빈의 이름 @Bean 메소드 이름 (getBean()에서 사용됨) 빈의 클래스 빈 오브젝트를 어떤 클래스를 이용해서 만들지 정의 빈의 의존 오브젝트 생성자나 수정자 메소드를 통해 의존 오브잭트를 주입 의존 오브젝트는 하나 이상일 수 있음 connecitonMaker() 전환 자바 코드 설정 정보 XML 설정 정보 빈 설정 파일 @Configuration 빈 이..
-
1장) 1.6 싱글톤 레지스트리와 오브젝트 스코프 ~ 1.7 의존관계 주입(IoC)Java & Spring/토비의 스프링 3.1 2021. 5. 21. 10:38
1장 오브젝트와 의존관계 1.6 싱글톤 레지스트리와 오브젝트 스코프 스프링의 Application Context는 예시로 직접 만들었던 오브젝트 팩토리(DaoFactory)와 차이가 있다. 오브젝트의 동일성과 동등성으로 말하면 이해하기 쉽다. DaoFactory는 호출할 때마다 새로운 오브젝트를 만들어서 반환한다. (다른 객체 -> 동등성) 스프링의 Application Context에 DaoFactory를 설정정보로 등록(@Configuration)하고 getBean으로 빈을 호출하면 같은 주소값을 가진 오브젝트를 반환한다. (같은 객체 -> 동일성) 싱글톤 레지스트리로서 Application Context Application Context는 IoC 컨테이너이자 싱글톤을 저장하고 관리하는 싱글톤 레지..
-
1장) 1.3 DAO의 확장 ~ 1.5 스프링의 IoCJava & Spring/토비의 스프링 3.1 2021. 5. 17. 15:03
1장 오브젝트와 의존관계 1.3 DAO의 확장 모든 오브젝트는 관심사가 바뀔 때마다 변경이 일어난다. 앞서 팩토리 메소드 패턴을 통해 변화의 성격이 다른 것을 분리해서, 서로 영향을 주지 않고 독립적으로 변경하도록 리팩토링을 했다. 이번 장에서는 상속관계가 아닌 완전한 독립 클래스로 만들어보자. public class UserDao { private SimpleConnectionMaker; public UserDao() { simpleConnectionMaker = new SimpleConnectionMaker(); } public void add(User user) throws ClassNotFoundException, SQLEXception { Connection c = simpleConnection..