look-forest

예외 처리 이슈 해결리포지토리가 던지는 SQLException 체크 예외를 런타임 예외로 전환해서 서비스 계층에 던지면 서비스 계층이 해당 예외를 무시할 수 있기 때문에, 특정 구현 기술에 의존하는 부분을 제거하고 서비스 계층을 순수하게 유지할 수 있다. 이로써 throws SQLException가 제거되어 서비스 계층의 순수성을 유지할 수 있게 되었다.덕분에 향후 JDBC에서 다른 구현 기술로 변경하더라도 서비스 계층의 코드를 변경하지 않고 유지할 수 있다. 예외 처리를 하고 싶다면리포지토리에서 넘어오는 특정한 예외의 경우 복구를 시도할 수도 있다. 그런데 위 방식은 항상 MyDbException 이라는 예외만 넘어오기 때문에 예외를 구분할 수 없는 단점이 있다. 만약 특정 상황에는 예외를 잡아서 복구..

요약1. 체크 예외 단점 : (복구할 수 없음에도 강제하므로) 번거로움, 의존 관계 이슈 2. 기본적으로 언체크 예외 사용할 것.  3. 체크 예외는 비즈니스 로직상 의도적으로 던지는 예외에만 사용 (=> Exception으로 퉁쳐서 사용하면 의미가 사라지니 사용X)예외 기본예외에 대해서는 2가지 기본 규칙을 기억하자.예외는 잡아서 처리하거나 던져야 한다.예외를 잡거나 던질 때 지정한 예외뿐만 아니라 그 예외의 자식들도 함께 처리된다.참고: 예외를 처리하지 못하고 계속 던지면 어떻게 될까?자바 main() 쓰레드의 경우 예외 로그를 출력하면서 시스템이 종료된다.웹 애플리케이션의 경우 여러 사용자의 요청을 처리하기 때문에 하나의 예외 때문에 시스템이 종료되면 안된다.WAS가 해당 예외를 받아서 처리하는데,..

애플리케이션 구조 - 순수한 서비스 계층 시간이 흘러서 UI(웹) 와 관련된 부분이 변하고, 데이터 저장 기술을 다른 기술로 변경해도, 핵심 비즈니스 로직이 들어있는 서비스 계층은 최대한 변경없이 유지되어야 한다. 서비스 계층은 가급적 비즈니스 로직만 구현하고 특정 구현 기술에 직접 의존해서는 안된다. 이렇게 하면 향후 구현 기술이 변경될 때 변경의 영향 범위를 최소화 할 수 있다. 순수 JDBC로 구현 시 문제점트랜잭션을 사용하기 위해서 javax.sql.DataSource, java.sql.Connection, java.sql.SQLException 같은 JDBC 기술에 의존해야 한다. 향후 JDBC에서 JPA 같은 다른 기술로 바꾸어 사용하게 되면 서비스 코드도 모두 함께 변경해야 한다.핵심 비즈니..

트랜잭션 - 개념 이해데이터를 파일이 아닌 데이터베이스에 저장하는 가장 대표적인 이유는 바로 트랜잭션이라는 개념을 지원하기 때문.데이터베이스에서 트랜잭션은 하나의 거래를 안전하게 처리하도록 보장해주는 것을 뜻한다. 예시)  5000원 계좌이체1. A의 잔고를 5000원 감소2. B의 잔고를 5000원 증가 데이터베이스가 제공하는 트랜잭션 기능을 사용하면 1,2 둘다 함께 성공해야 저장하고, 중간에 하나라도 실패하면 거래 전의 상태로 돌아갈 수 있다.모든 작업이 성공해서 데이터베이스에 정상 반영하는 것을 커밋(Commit)이라 하고,작업 중 하나라도 실패해서 거래 이전으로 되돌리는 것을 롤백(Rollback)이라 한다. 트랜잭션 ACID트랜잭션은 ACID라하는 원자성(Atomicity), 일관성(Consi..

커넥션 풀데이터베이스 커넥션을 획득할 때는 다음과 같은 복잡한 과정을 거친다.이렇게 커넥션을 새로 만드는 것은 과정도 복잡하고 시간도 많이 많이 소모되는 일이다.이런 문제를 한번에 해결하는 아이디어가 바로 커넥션을 미리 생성해두고 사용하는 커넥션 풀이라는 방법이다. 애플리케이션을 시작하는 시점에 커넥션 풀은 필요한 만큼 커넥션을 미리 확보해서 풀에 보관한다.커넥션 풀에 들어 있는 커넥션은 TCP/IP로 DB와 커넥션이 연결되어 있는 상태이기 때문에 언제든지 즉시 SQL을 DB에 전달할 수 있다.이제는 커넥션 풀을 통해 이미 생성되어 있는 커넥션을 객체 참조로 그냥 가져다 쓰기만 하면 된다커넥션을 모두 사용하고 나면 이제는 커넥션을 종료하는 것이 아니라, 다음에 다시 사용할 수 있도록 해당 커넥션을 그대로..

오류 페이지는 단순히 고객에게 오류 화면을 보여주고 끝이지만,API는 각 오류 상황에 맞는 오류 응답 스펙을 정하고, JSON으로 데이터를 내려주어야 한다.지금부터 API의 경우 어떻게 예외 처리를 하면 좋은지 알아보자.1. 서블릿 오류 페이지 방식 구현에러페이지를 처리하는 컨트롤러에 요청 Accept 헤더가 application/json일 경우 응답하는 API를 만들어야 한다. 2. 스프링 부트 기본 오류 처리 구현BasicErrorController는 API 응답 방식도 구현이 되어 있다.@RequestMapping(produces = MediaType.TEXT_HTML_VALUE)public ModelAndView errorHtml(HttpServletRequest request, HttpServl..

Spring MVC에서 예외 처리 방법을 알아보자.1. WAS 서블릿 컨테이너가 제공하는 예외 처리 및 오류 페이지2. 스프링에서 제공하는 예외 처리 및 오류 페이지1. 서블릿 예외 처리서블릿은 다음 2가지 방식으로 예외 처리를 지원한다.Exception (예외) → 500 에러response.sendError(HTTP 상태 코드, 오류 메시지)자바의 메인 메서드를 직접 실행하는 경우 main 이라는 이름의 쓰레드가 실행된다. 실행 도중에 예외를 잡지 못하고 처음 실행한 main() 메서드를 넘어서 예외가 던져지면, 예외 정보를 남기고 해당 쓰레드는 종료된다. 웹 애플리케이션은 사용자 요청별로 별도의 쓰레드가 할당되고, 서블릿 컨테이너 안에서 실행된다. 애플리케이션에서 try ~ catch로 예외를 잡아..

로그인 여부를 체크하는 로직을  모든 컨트롤러에 공통 적용해야 하는 문제점이 남아있다.(단일 책임 원칙 위배)이렇게 애플리케이션 여러 로직에서 공통으로 관심이 있는 있는 것을 공통 관심사(cross-cutting concern)라고 한다.이러한 공통 관심사는 스프링의 AOP로도 해결할 수 있지만, 웹과 관련된 공통 관심사는 지금부터 설명할 서블릿 필터 또는 스프링 인터셉터를 사용하는 것이 좋다  서블릿 필터필터는 서블릿이 지원하는 수문장이다. 필터의 특성은 다음과 같다HTTP 요청 → WAS → 필터1,2,3,, → 서블릿 → 컨트롤러필터를 적용하면 필터가 호출 된 다음에 서블릿이 호출된다.필터에서 적절하지 않은 요청이라고 판단하면 거기에서 끝을 낼 수도 있다. (서블릿 호출X)참고로 스프링을 사용하는 ..