창의적으로 바쁘기

6장 AOP-2 정리 노션 페이지 스프링 AOP 자동 프록시 생성 프록시 팩토리 빈 방식의 한계로 인한 문제점 부가기능이 타깃 오브젝트마다 새로 만들어지는 문제 → ProxyFactoryBean 어드바이스 통해 해결 부가기능 적용이 필요한 타깃 오브젝트마다 비슷한 내용의 ProxyFactoryBean 설정정보 추가 → 어떻게 중복을 제거할까? 중복 문제의 접근 방법 다이내믹 프록시라는 런타임 코드 자동생성 기법을 통해 프록시 클래스 코드의 중복문제 해결 → ProxyFactoryBean설정 문제에도 자동등록/생성 기법 사용할 수 있을까? → 일정한 타깃 빈의 목록을 제공하면, 자동으로 각 타깃 빈에 대한 프록시를 만들어주는 방법 → 하지만 지금까지는 위의 방법이 없었음 빈 후처리기를 이용한 자동 프록시 ..

AOP-1 정리 노션 페이지 AOP 적용 대상 : 선언적 트랜잭션 6.1 트랜잭션 코드의 분리 6.1.1 메소드 분리 비즈니스 로직과 트랜잭션 경계설정은 완벽하게 독립적 트랙잭션의 시작과 종료 사이에 비즈니스 로직이 실행되는 조건만 지키면 됨 → 비즈니스 로직을 담당하는 코드를 메소드로 추출해서 독립 6.1.2 DI를 사용한 클래스의 분리 비즈니스 로직 분리 but 트랜잭션 담당 코드가 여전히 서비스 안에 있음 DI 의 기본 아이디어 : 실제 사용할 오브젝트의 클래스 정체는 감추고 인터페이스 통해 간접 접근 → 이로 인해 구현 클래스를 외부에서 자유롭게 변경 가능 인터페이스 이용해 구현 클래스 클라이언트에 노출하지 않고 런타임 시에 DI를 통해 적용하는 방법을 쓰는 이유 → 구현 클래스를 상황에 따라 바..

5장 서비스 추상화 트랜잭션 서비스 추상화 작업 중 예외가 발생해 완료 되지 않았다면 ? -> 작업이 시작되지 않은 것처럼 초기 상태로 되돌려 놓아야한다. 이것이 트랜잭션이다. 트랜잭션 : 더 이상 나눌 수 없는 단위 작업 (원자성) 트랜잭션 경계 설정 트랜잭션 롤백 : 취소 작업 트랜잭션 커밋 : 작업 확정시킴 트랜잭션 경계 : 트랙잭션이 시작되고 끝나는 위치 롤백을 위해서는 여러 개의 작업을 1개의 트랜잭션으로 관리 해야 함 트랜잭션 동기화 JDBC 기준, 트랜잭션 유지하려면 시작-끝까지 같은 Connection 유지 -> Connection 파라미터로 전달하면 데이터 엑세스 기술에 독립적 X -> JPA 등으로 구현 방식 변경하면 인터페이스 DAO 다 수정해야함(DI 적용 안 되는 것) -> 동기화..

예외의 종류와 특징 체크예외 : 명시적인 처리가 필요한 예외, throw를 통해 발생시킬 수 있는 예외 = 일반적인 예외 Error java.lang.Error 클래스의 서브클래스 시스템에 비정상적인 상황이 발생했을 경우(VM에서 발생시키는 것, 애플리케이션 코드 X) 애플리케이션에서는 이런 에러에 대한 처리는 신경 쓰지 않아도 됨 Exception 애플리케이션 코드 작업 중에 예외상황이 발생했을 경우 체크 예외 RuntimeException 클래스 상속 X 언체크 예외 = 런타임 예외 RuntimeException 클래스 상속 O - 특별하게 다룸 명시적인 예외처리 X (catch로 잡거나 throws 선언 안 해도 됨) NullPointerException, IllegalArgumentExceptio..

2장 테스트 만들어진 코드를 확신할 수 있게 해주고, 변화에 유연하게 대처할 수 있게 자신감을 주는 기술 웹을 통한 DAO 테스트 방법의 문제점 서비스 클래스, 컨트롤러, JSP 뷰 등 모든 레이어의 기능을 다 만든 후에야 테스트가 가능 에러 메시지와 호출 스택 정보만으로 원인 찾기 힘듦 DAO를 테스트 하려고 만든 다른 레이어의 코드 때문에 에러가 날 수 있음 테스트 하고 싶은 대상에 다른 계층의 코드, 컴포넌트 서버의 설정 상태가 모두 영향을 줌 작은 단위의 테스트 가능한 작은 단위로 쪼개서 집중 -> 관심사의 원리 적용 UserDaoTest 를 수행할 때 웹 인터페이스, 이를 위한 MVC 클래스, 서비스 오브젝트, 서버 배포 필요가 없음 -> 단위 테스트(Unit Test) 통제할 수 없는 외부의 ..