JDBC JDBC Java Database Connectivity의 약자 자바 프로그램에서 DB에 접속할 수 있게 해 주는 인터페이스(API)로, 자바 프로그램과 DBMS 사이에 위치 각 DBMS는 자신의 DB에 맞도록 JDBC 인터페이스를 JDBC 드라이버라는 라이브러리로 구현해서 제공 JDBC는 DBMS에 맞는 드라이버를 사용해서 DB에 연결 JDBC를 사용하면, DBMS를 변경할 때 드라이버만 변경하면 되므로 변경이 용이해짐 인터페이스 JDBC 인터페이스는 java.sql에 다음과 같은 표준 인터페이스를 제공 java.sql.Connection: DB와 연결하는 기능을 담당하는 인터페이스 java.sql.Statement: SQL을 보내기 위한 통로 기능을 담당하는 인터페이스 java.

Service Repository 구분 이유 Service Repository 구분 이유 Repository는 DB에 접근하는 코드 영역 DB 관련 문제가 생기면 여기만 확인하면 됨 Service는 repository를 이용해 비즈니스 로직을 처리하는 코드 영역 Controller가 service를 호출하면, 비즈니스 로직을 수행하고 결과를 controller에게 넘겨 줌 비즈니스 로직에 문제가 생기면 여기만 확인하면 됨 이렇게 DB 접근과 비즈니스 로직을 분리하면, 어디에서 문제가 발생했는지 알기 쉽고, 코드가 잘 모듈화됨 References https://www.inflearn.com/questions/77417/repository-vs-service-%EC%9D%98-%EC%97%AD%ED%95%A0%EC%9D%98-%EC%B0%A8%EC%9D%B4%EC%A0%90 https://velog.io/@jybin96/Controller-Service-Repository-%EA%B0%80-%EB%AC%B4%EC%97%87%EC%9D%BC%EA%B9%8C

Builder Pattern Builder Pattern 객체를 생성할때 사용하는 디자인 패턴 객체를 생성하는 방법을 정의하는 클래스와 표현하는 법을 정의하는 클래스를 분리 별도의 builder 클래스를 통해 메소드를 chaining 형태로 호출해서 필요한 데이터를 순차적으로 입력받음 다양한 구성의 인스턴스를 만들 수 있음 구현 방법 public class Test { private final int id; private final String name; private final String addr; private Test(TestBuilder builder) { this.id = builder.id; this.name = builder.name; this.addr = builder.addr; } public static class TestBuilder { private int id; private String name = "John doe"; // Default private String addr = "Chunryang"; // Default public TestBuilder(int id) { this.

JPA Fetch Join JPA Join 비교 JPA는 일반 join과 fetch join 존재 일반 join JPQL에서 조회하는 entity만 영속화 연관된 entity의 데이터가 필요 없을 때 사용 연관된 entity의 데이터를 사용하는 경우 N + 1 문제 혹은 LazyInitializationException 발생 가능 Fetch join JPQL에서 조회하는 entity에 연관된 모든 엔티티도 같이 영속화 연관된 entity의 데이터가 있기 때문에 N + 1 문제가 발생하지 않음 연관된 entity의 데이터를 사용하는 경우에만 fetch join을 하는 게 좋음 Fetch join 사용 방법 SELECT p FROM pickup p JOIN FETCH p.

Spring Interceptor Spring Interceptor 컨트롤러에 들어온 HttpRequest와 컨트롤러가 응답하는 HttpResponse를 가로채어 추가 로직을 실행하는 모듈 관리자 인증 / 로그인 처리 등의 용도로 사용 가능 Filter와 달리 DispatcherServlet이 실행된 후 호출됨 HandleInterceptor 인터페이스를 상속받아서 구현 가능. 다음 메소드들을 구현해야 함 preHandle 메서드는 컨트롤러로 보내기 전에 동작 postHandle 메서드는 컨트롤러의 handler 처리가 끝난 후 동작 afterCompletion 메서드는 view가 렌더링 된 후 실행됨 HandlerInterceptorAdapter 클래스를 상속받는 경우 preHandle 메서드만 구현해도 됨 인터셉터 설정 방법 WebMvcConfigurer 인터페이스를 구현한 설정 클래스 에서 인터셉터를 설정 가능 설정 클래스에서 addInterceptors 메서드를 구현해 인터셉터를 추가 가능 이 메소드에 입력으로 들어온 registry에 addInterceptor 메소드를 호출해서 추가 가능 addPathPatterns, excludePathPatterns 등을 적용해 추가 혹은 제외할 URL 패턴을 등록 가능 References https://velog.

Servlet JSP Servlet 개발자가 직접 HTTP 메시지를 파싱하거나, 응답 메시지를 만드는 등의 작업을 하기에는 너무 번거로움 개발자가 HTTP 스펙을 편리하게 사용하기 위한 기술이 필요 서블릿은 HTTP 요청에 동적인 처리가 가능한 서버 측의 자바 프로그램 및 그 기술 자바 코드 안에 HTML 코드가 있는 형태 Servlet container 톰캣과 같이 서블릿을 지원하는 WAS를 서블릿 컨테이너라고 함 다음과 같은 기능 제공 서블릿의 생명 주기를 관리 소켓을 통해 web server와 통신 멀티 스레드를 지원하므로 개발자가 신경 안 써도 됨 (스레드 풀 제공) 보안 지원 동작 과정 HTTP 요청이 서블릿 컨테이너(WAS)로 들어옴 서블릿 컨테이너는 HttpServletRequest, HttpServletResponse 객체를 생성해서 서블릿 객체를 호출 개발자는 HttpServletRequest 에서 요청 정보를 꺼내거나 HttpServletResponse 에 응답 정보를 입력 가능 요청받은 정보에 해당되는 서블릿을 찾음 해당 서블릿이 존재하지 않는다면 init 메소드를 실행해서 생성 후 메모리에 올림 서블릿에서 service 메소드를 호출한 후 동적인 정보를 담은 HTML 생성 서블릿 컨테이너는 HttpServletResponse 객체를 이용해 HTTP 응답 정보를 생성하고 보냄 Servlet 생명 주기 init 서블릿이 메모리에 없는 경우 메모리에 올리고 초기화하는 메소드 서블릿 객체는 싱글톤으로 관리됨 service 요청을 받고 응답을 반환할 때 실행되는 메소드 Get/Post 요청에 따라 doPost 혹은 doGet 등을 호출 각각의 요청에 따라 개별 스레드에서 실행됨 destory 서블릿 컨테이너가 서블릿에 종료 요청을 하면 실행되는 메소드 서블릿 객체를 메모리에서 제거 JSP Java를 이용한 서버 사이드 템플릿 엔진 서블릿은 자바 코드에 HTML 코드를 넣음 고정된 부분까지 자바를 통해 HTML을 만들어야 하고, 이는 비효율적 HTML 내부에서 동적으로 변경해야 하는 부분만 자바 코드를 넣는 것이 더욱 편리하기 때문에, JSP가 등장함 HTML 코드에 자바 코드를 넣어 동적인 웹 페이지 생성 가능 현재는 다른 템플릿 엔진 (Ex: Thymeleaf)에 밀려 사장되는 추세 JSP와 MVC JSP 만으로도 동적인 페이지를 생성 가능함 그러나 JSP만 사용하는 경우 다양한 코드가 모두 HTML에 노출되어 있음 또한 하나의 JSP 파일에 view 영역과 비즈니스 로직이 섞여 있게 됨 이런 이유들로 JSP만 사용해서는 유지보수가 힘듦.

@Transactional @Transactional @Transactional은 Spring에서 메서드가 트랜잭션이 되도록 보장해주는 annotation 주로 Service 클래스 혹은 Service 내부의 메서드들에 붙음 Service 클래스에 붙으면 모든 메서드에 @Transactional을 붙인 것과 동일 @Transactional이 붙은 메서드는 트랜잭션 성공 여부에 따라 커밋 또는 롤백 작업이 정상 수행되면 커밋 메서드 실행 중 작업이 하나라도 실패하면 전체 작업을 취소 (Rollback) 다음과 같은 옵션을 제공 가능 isolation: 트랜잭션 격리 수준 설정 propagation: 다른 트랜잭션 호출에 대한 전파 옵션 rollbackFor, noRollbackFor: 어떤 상황에 롤백을 할 지 / 안 할 지 결정 timeout: 지정 시간 내에 메서드가 수행되지 않으면 rollback readonly: 읽기 전용 설정 Test @Transactional 테스트 메서드에 @Transactional이 붙으면, 해당 메서드가 트랜잭션이 되면서, 종료시 롤백됨 롤백시키고 싶지 않다면 Rollback(value=false)를 적용시키면 됨 롤백 여부와 상관없이, DB에 auto increment로 설정된 필드에서 증가한 값은, 해당 값이 유지됨 Auto increment는 트랜잭션 밖에서 실행되기 때문 Auto increment가 트랜잭션 내에 있다면, 동시성이 저해됨 @Transactional(readonly=true) 기본적으로 @Transactional 어노테이션의 readonly 값은 false임 그러나 읽기만 필요한 메서드의 경우 이 readonly 값을 true로 두면, 메서드 내부에서 flush가 일어나지 않음 트랜잭션이 커밋되어도, DB가 변경되지 않음 그러나 강제로 flush를 호출한다면 변경될 수 있음 readonly=true 장점 개발자가 해당 메서드가 읽기 전용이라는 점을 알게 쉽게 함 영속성 컨텍스트에 관리를 받지 않아 성능상 이점이 존재 변경에 대한 감지를 하지 않음 스냅샷을 가지고 있지 않아도 됨 더 낮은 isolation level을 가지고 있음 Repetable Read를 위해 필요한 Transaction ID를 부여하지 않아 오버헤드 감소 Master-Slave DB 구조에서 slave DB를 읽어 부하를 분산시킬 수 있음 References https://tecoble.

Java Reflection Java Reflection Reflection은 Java에서 구체적인 클래스 타입을 알지 못해도 해당 클래스의 정보에 접근하게 해주는 자바 API JVM의 클래스 로더가 Class 타입의 객체를 메모리의 힙 영역에 저장해 둔 것을 가져올 수 있게 해 줌 런타임 시에 클래스 및 관련 정보를 가져올 수 있음 Class 타입의 객체 가져오는 법 다음과 같은 방법을 이용해 Class 타입의 객체를 가져 올 수 있음 클래스가 있는 경우: 클래스.class 인스턴스가 있는 경우: 인스턴스.getClass() 클래스 이름을 아는 경우: Class.

Spring Security 소개 Spring Security Spring에서 인증, 인가 등 애플리케이션의 보안을 담당하는 하위 프레임워크 보안과 관련한 많은 기능을 제공하고, 개발자가 직접 작성해야 하는 부분을 줄여 줌 OAuth 2.0에 대한 지원도 제공 Web security와 Method security라는 두 개의 구조 존재 Web security 클라이언트와 servlet 사이에 filter를 두어 인증, 로깅 등을 수행하는 방법 Spring security가 여러 filter를 제공하기도 하며, 개발자가 직접 filter를 구현 가능 Method security 권한 관리가 필요한 각 메소드마다 인증 관련 설정하는 방법 메소드별로 설정이 가능하므로, 세밀한 권한 관리 가능 @SpringBootApplication이 붙은 클래스에서 @EnableGlobalMethodSecurity(securedEnable = true)를 설정해야 함 이후 메소드에 @Secure("ROLE_USER") 등을 붙여 권한 설정을 해 줄 수 있음 Web security와 Method Security를 둘 다 사용하는 것이 권장됨 Session 기반의 인증 시스템을 사용할 수도, JWT 등의 Token 기반의 인증 시스템을 활용할 수도 있음 References https://mangkyu.

JPA Persistence Context JPA Persistence Context JPA의 영속성 컨텍스트란 엔티티를 영구적으로 저장하는 일종의 가상 DB Application과 DB 사이에서 객체를 보관하는 논리적 개념 Entity Manager 영속성 컨텍스트의 엔티티에 접근 및 관리가 가능한 인터페이스 Spring Bean으로 등록되어 @Autowired 사용 가능 메서드 예시 em.persist(entity)를 통해 엔티티를 영속성 컨텍스트에 저장 가능 em.flush()를 통해 현재까지의 변경 내용을 DB에 반영 가능 em.find(Member.class, "memberA")를 통해 memberA 멤버를 조회 가능 Entity 생명 주기 엔티티는 비영속, 영속, 준영속, 삭제 등의 생명 주기를 가짐 비영속: 엔티티 객체가 영속성 컨텍스트와 관련이 없는 상태 영속: 엔티티 객체가 영속성 컨텍스트에 저장되어 관리받는 상태 준영속: 엔티티 객체가 영속성 컨텍스트에 저장되었다가 분리된 상태 삭제: 엔티티 객체가 영속성 컨텍스트와 DB에서 삭제된 상태 영속성 컨텍스트의 특징 다음과 같은 특징들 존재 1차 캐시 영속성 컨텍스트 내부의 캐시 영속 상태의 엔티티를 저장 id - 엔티티 형태로 데이터를 저장하고, 조회 성능을 높여 줌 동일성 보장 영속성 컨텍스는 영속 상태의 엔티티들의 동일성을 보장함 같은 엔티티를 조회했을 때 같은 인스턴스를 얻을 수 있음 쓰기 지연 엔티티를 영속성 컨텍스트에 저장해도 바로 DB에 업데이트 하지 않음 INSERT 쿼리들은 영속성 컨텍스트 내의 쿼리 저장소에 저장됨 flush() 혹은 트랜잭션이 커밋되면 저장된 쿼리들이 나감 변경 감지 영속성 컨텍스트는 엔티티가 수정되면 변경 사항을 자동으로 체크함 flush() 혹은 트랜잭션이 커밋되면 UPDATE 쿼리들이 나감 References 김영한 - 자바 ORM 표준 JPA 프로그래밍 - 기본편(https://www.