스프링 부트 핵심 원리와 활용

Java-Ecosystem · 2025-03-31

자바 애노테이션

애노테이션 (Annotation) 프로그램 실행 중에 읽어서 사용할 수 있는 특별한 주석 내부에서 리플렉션 같은 기술 등을 활용 e.g. Class ,Method ,Field ,Constructor 클래스는 getAnnotation() 제공 참고: 본래 주석은 코드가 아니므로 컴파일 시점에 모두 제거됨 코드에 메모를 달아 놓는 것처럼 코드에 대한 메타데이터를 표현 프로그램 코드가 아니어서 애노테이션이 달린 메서드를 호출해도 영향을 주지 않음 애노테이션 정의 규칙 @Retention(RetentionPolicy.RUNTIME) @Target(ElementType.TYPE) @Documented public @interface AnnoElement { String value(); int count() default 0; String[] tags() default {}; Class<? extends MyLogger> annoData() default MyLogger.class; //MyLogger data(); // 다른 타입은 적용X } 정의: @interface 키워드 속성: 애노테이션은 속성을 가질 수 있음 요소 이름 메서드 형태로 정의 괄호()를 포함하되 매개변수는 없어야 함 데이터 타입 기본 타입 (int, float, boolean 등) String Class (메타데이터) 또는 인터페이스 (직접 정의한 것이 아닌 Class에 대한 정보) enum 다른 애노테이션 타입 위의 타입들의 배열 앞서 설명한 타입 외에는 정의 불가 (즉, 일반적인 클래스를 사용할 수 없음) 예) Member , User , MyLogger default 값 요소에 default 값을 지정 가능 예: String value() default "기본 값을 적용합니다."; 반환 값 void 반환 타입 사용 불가 예외 예외 선언 불가 메타 애노테이션: 애노테이션을 정의하는데 사용하는 특별한 애노테이션 @Retention 애노테이션의 생존 기간을 지정 종류: RetentionPolicy enum RetentionPolicy.SOURCE (특별한 경우 사용) 소스코드에서만 생존 -> 컴파일 시점에 제거 RetentionPolicy.CLASS (기본값, 그러나 거의 사용 X) 컴파일 후 .class 파일까지 생존 -> 자바 실행 시점에 제거 RetentionPolicy.RUNTIME (대부분 사용) 자바 실행 중에도 생존 런타임에 리플렉션으로 읽을 수 있어 자주 사용됨 @Target 애노테이션을 적용할 수 있는 위치 지정 지정하지 않은 곳에 애노테이션을 적용하면 컴파일 오류 발생 종류: ElementType enum 주로 TYPE, FIELD, METHOD 사용 e.g. 배열로 여러 위치도 적용 가능 @Target({ElementType.METHOD, ElementType.TYPE}) @Documented (보통 함께 사용) 자바 API 문서를 만들 때, 해당 애노테이션이 문서에 포함되어 표현되도록 지정 @Inherited 자식 클래스가 애노테이션을 상속 받을 수 있게 함 애노테이션 사용법 기본 @AnnoElement(value = "data", count = 10, tags = {"t1", "t2"}) public class ElementData1 { } 배열 항목이 하나인 경우 {} 생략 가능 & default 항목은 생략 가능 @AnnoElement(value = "data", tags = "t1") public class ElementData2 { } 입력 요소가 하나인 경우 value 키 생략 가능 (value = "data" 와 동일) @AnnoElement("data") public class ElementData3 { } 애노테이션과 상속 public interface Annotation { boolean equals(Object obj); int hashCode(); String toString(); Class<? extends Annotation> annotationType(); //애노테이션 타입 반환 } 자바에서 애노테이션은 특별한 형태의 인터페이스로 간주 모든 애노테이션은 java.lang.annotation.Annotation 인터페이스를 묵시적으로 상속 받음 @interface로 정의하면 자바 컴파일러가 자동으로 Annotation 인터페이스를 확장 애노테이션 정의 public @interface MyCustomAnnotation {} 자바가 자동으로 처리 public interface MyCustomAnnotation extends java.lang.annotation.Annotation {} 다만, 애노테이션 사이에는 상속이라는 개념이 존재 X 애노테이션은 오직 Annotation 인터페이스만 상속 애노테이션은 다른 애노테이션이나 인터페이스를 직접 상속할 수 없음 @Inherited 애노테이션을 적용한 클래스의 자식 클래스도 해당 애노테이션을 부여 받을 수 있음 클래스 상속에서만 작동 (인터페이스 구현에는 적용 X) 자바 기본 애노테이션 @Override 메서드 재정의가 정확하게 잘 되었는지 컴파일러가 체크하는데 사용 @Deprecated 더 이상 사용되지 않는다는 뜻을 표현하며, 적용된 기능은 사용을 권장하지 않음 컴파일 시점에 경고를 나타내지만, 프로그램은 작동 옵션 since : 더 이상 사용하지 않게된 버전 정보 forRemoval : 미래 버전에 코드가 제거될 예정 (더더욱 강력한 경고) 예제 @Deprecated -> 진짜 쓰지마 @Deprecated(since = "2.4", forRemoval = true) -> 진짜진짜 쓰지마 @SuppressWarnings 자바 컴파일러가 문제를 경고하지만, 개발자가 문제를 잘 알고 있으니 경고하지 말라고 지시 왠만하면 사용 X (제네릭 쓰다보면 개발자가 책임지겠다고 쓸 때 정도 있음) 옵션 all: 모든 경고 억제 deprecation: deprecated 코드를 사용할 때 발생하는 경고 억제 unchecked: 제네릭 타입과 관련된 unchecked 경고 억제 serial: Serializable 인터페이스를 구현할 때 serialVersionUID 필드를 선언하지 않은 경우 발생하는 경고 억제 rawtypes: 제네릭 타입이 명시되지 않은(raw) 타입을 사용할 때 발생하는 경고 억제 unused: 사용되지 않는 변수, 메서드, 필드 등을 선언했을 때 발생하는 경고 억제 참고: 애노테이션 기반 검증기 활용 예제 public class Validator { public static void validate(Object obj) throws Exception { Field[] fields = obj.getClass().getDeclaredFields(); for (Field field : fields) { field.setAccessible(true); // @NotEmpty 어노테이션 검사 if (field.isAnnotationPresent(NotEmpty.class)) { String value = (String) field.get(obj); NotEmpty annotation = field.getAnnotation(NotEmpty.class); if (value == null || value.isEmpty()) { throw new RuntimeException(annotation.message()); } } // @Range 어노테이션 검사 if (field.isAnnotationPresent(Range.class)) { long value = field.getLong(obj); Range annotation = field.getAnnotation(Range.class); if (value < annotation.min() || value > annotation.max()) { throw new RuntimeException(annotation.message()); } } } } } Reference 김영한의 실전 자바 - 고급 2편, I/O, 네트워크, 리플렉션

Java-Ecosystem · 2025-03-25

자바 리플렉션

리플렉션 클래스가 제공하는 다양한 정보(메타 데이터)를 런타임에 동적으로 분석하고 사용하는 기능 e.g. 스프링 프레임워크가 내가 만든 클래스를 대신 생성해주는 경우 메타데이터 종류 클래스 e.g. 클래스 이름, 접근 제어자, 부모 클래스, 구현한 인터페이스 필드 e.g. 필드 이름, 타입, 접근 제어자 런타임에 동적으로 해당 필드 값을 읽거나 수정 가능 메서드 e.g. 메서드 이름, 반환 타입, 매개변수 정보 런타임에 동적으로 메서드 조회 및 호출 가능 생성자 e.g. 매개변수 타입 및 개수 런타임에 동적으로 생성자 조회 및 객체 생성 가능 주의점 리플렉션 코드는 특별한 상황에서 사용 공통 문제를 해결하는 유틸리티, 프레임워크, 라이브러리 개발 테스트 등 일반적인 애플리케이션은 권장 X 무분별한 리플렉션 사용은 코드의 가독성과 안정성이 크게 저하 e.g. private 직접 접근은 객체 지향 원칙을 위반 (캡슐화 및 유지보수성 저하) 클래스 내부 구조나 구현 세부사항이 변경되면 쉽게 깨지거나 버그를 초래 리플렉션은 문자를 활용하므로, 필드 및 메서드 이름 변경 시 컴파일러가 놓침 클래스 메타데이터 클래스의 메타데이터는 Class 클래스로 표현 Class 조회 방법 클래스에서 찾기 클래스명.class e.g. Class<BasicData> basicDataClass1 = BasicData.class; 인스턴스에서 찾기 인스턴스.getClass() e.g. BasicData basicInstance = new BasicData(); Class<? extends BasicData> basicDataClass2 = basicInstance.getClass(); 문자로 찾기 Class.forName(패키지명문자열) e.g. String className = "reflection.data.BasicData"; Class<?> basicDataClass3 = Class.forName(className); 기본 정보 탐색 클래스 이름 경로 포함 이름: basicData.getName() //reflection.data.BasicData 클래스 이름: basicData.getSimpleName() //BasicData 패키지 basicData.getPackage() //package reflection.data 부모 클래스 basicData.getSuperclass() //class java.lang.Object 구현한 인터페이스 basicData.getInterfaces() //[] 조건 판별 basicData.isInterface() //false basicData.isEnum() //false basicData.isAnnotation() //false 수정자 정보 (규칙있는 숫자로 리턴) basicData.getModifiers() //1 참고: 수정자는 접근제어자와 비접근제어자(기타 수정자)로 분류 접근 제어자: public , protected , default ( package-private ), private 비 접근 제어자: static , final , abstract , synchronized , volatile 등 메서드 메타데이터 Method 클래스로 표현 (클래스 메타데이터를 통해 획득 가능) 메서드 메타데이터 조회 getMethod(메서드이름, 매개변수타입) 해당 클래스와 상위 클래스에서 상속된 모든 public 메서드 중 지정 메서드 조회 e.g. String methodName = "hello"; Method method = helloClass.getMethod(methodName, String.class); getDeclaredMethod(메서드이름, 매개변수타입) 해당 클래스에서 선언된 모든 메서드 중 지정 메서드 조회 e.g. String methodName = "hello"; Method method = helloClass.getMethod(methodName, String.class); getMethods() 해당 클래스와 상위 클래스에서 상속된 모든 public 메서드를 반환 e.g. Class<BasicData> helloClass = BasicData.class; Method[] methods = helloClass.getMethods(); getDeclaredMethods() 해당 클래스에서 선언된 모든 메서드를 반환 접근 제어자에 관계 X, 상속된 메서드 포함 X e.g. Class<BasicData> helloClass = BasicData.class; Method[] declaredMethods = helloClass.getDeclaredMethods(); 동적 메서드 호출 메서드 이름을 입력 받으면, 호출 대상 메서드를 동적으로 조회해 호출 가능 getMethod(), getDeclaredMethod()로 메서드 동적 조회 Method 객체의 invoke(인스턴스, 인자1, ...) 로 메서드 호출 e.g. Class<? extends BasicData> helloClass = helloInstance.getClass(); String methodName = "hello"; Method method = helloClass.getDeclaredMethod(methodName, String.class); Object returnValue = method.invoke(helloInstance, "hi"); 필드 메타데이터 Field 클래스로 표현 (클래스 메타데이터를 통해 획득 가능) 필드 조회 getField(필드이름) 해당 클래스와 상위 클래스에서 상속된 모든 public 필드 중 지정 필드 조회 e.g. Field nameField = aClass.getField("name"); getDeclaredField(필드이름) 해당 클래스에서 선언된 모든 필드 중 지정 필드 조회 e.g. Field nameField = aClass.getDeclaredField("name"); getFields() 해당 클래스와 상위 클래스에서 상속된 모든 public 필드를 반환 e.g. Class<BasicData> helloClass = BasicData.class; Field[] fields = helloClass.getFields(); getDeclaredFields() 해당 클래스에서 선언된 모든 필드를 반환 접근 제어자에 관계 X, 상속된 필드 포함 X e.g. Class<BasicData> helloClass = BasicData.class; Field[] declaredFields = helloClass.getDeclaredFields(); 필드 값 변경 setAccessible(true) private 필드에 직접 접근해 변경할 수 있는 기능 e.g. nameField.setAccessible(true) 참고: private 메서드, 생성자에서도 사용 가능 (Method, Constructor) set(인스턴스, 변경값) 필드 값 변경 메서드 e.g. nameField.set(user, "userB") 생성자 메타데이터 Constructor 클래스로 표현 (클래스 메타데이터를 통해 획득 가능) 생성자 조회 getConstructor(매개변수타입) 해당 클래스와 상위 클래스에서 상속된 모든 public 생성자 중 지정 생성자 조회 e.g. Constructor<?> constructor = aClass.getConstructor(String.class); getDeclaredConstructor(매개변수타입) 해당 클래스에서 선언된 모든 생성자 중 지정 생성자 조회 e.g. Constructor<?> constructor = aClass.getDeclaredConstructor(String.class); getConstructors() 해당 클래스와 상위 클래스에서 상속된 모든 public 생성자를 반환 e.g. helloClass.getConstructors(); getDeclaredConstructors() 해당 클래스에서 선언된 모든 생성자를 반환 접근 제어자에 관계 X, 상속된 생성자 포함 X e.g. helloClass.getDeclaredConstructors(); 동적 인스턴스 생성 setAccessible(true) private 생성자에 직접 접근해 호출할 수 있는 기능 e.g. constructor.setAccessible(true) newInstance(인자) 생성자를 호출해 동적으로 객체 생성 e.g. Object instance = constructor.newInstance("hello") Reference 김영한의 실전 자바 - 고급 2편, I/O, 네트워크, 리플렉션

Java-Ecosystem · 2025-03-15

자바 I/O & 네트워크

Java-Ecosystem · 2025-02-28

QueryDSL Dive

Java-Ecosystem · 2025-01-13

Spring Data JPA Dive

Java-Ecosystem · 2025-01-09

JPA 활용 팁 2

Java-Ecosystem · 2024-11-26

스프링 핵심 원리 - 고급편

Java-Ecosystem · 2024-11-08

자바 멀티스레드와 동시성

Java-Ecosystem · 2024-10-02

자바 Collection Framework

Java-Ecosystem · 2024-09-05

자바 제네릭

Java-Ecosystem · 2024-09-04

자바 예외 기본

예외 계층 Object: 모든 객체의 최상위 부모 Throwable: 최상위 예외, 잡으면 안됨 (Error까지 잡히므로) Error 애플리케이션에서 복구 불가능한 시스템 예외 (메모리 부족, 심각한 시스템 오류…) 애플리케이션 개발자는 이 예외를 잡지 않아야 함 언체크 예외 Exception: 체크 예외 (런타임 예외 제외), 애플리케이션에서 개발자가 잡아야 할 실질적최상위 예외 RuntimeException: 언체크 예외 (=런타임 예외) 체크예외 VS 언체크 예외 핵심 언체크 예외는 throws 선언하지 않고 생략 가능 (자동 예외 던지기) 나머지는 동일 체크 예외 컴파일러가 체크하는 예외 체크 예외의 장단점 예외를 누락하지 않도록 컴파일러가 안전 장치 역할 (누락 시 컴파일 오류) 크게 신경쓰지 않고 싶은 예외까지 모두 반드시 잡거나 던져야 함 언체크 예외 컴파일러가 체크하지 않는 예외 중요 예외의 경우 throws를 선언해두면 IDE를 통해 개발자가 편리하게 인지 가능 (보통은 생략) 언체크 예외의 장단점 신경쓰고 싶지 않은 언체크 예외 무시 가능 개발자가 실수로 예외 누락 가능 예외 처리 기본 기본 규칙 예외는 잡아서 처리하거나 던져야 한다 예외를 잡는 코드: catch 예외를 던지는 코드: throws 예외를 잡거나 던질 때 지정한 예외 뿐만 아니라 그 예외의 자식들도 함께 처리된다 기본적으로 언체크(런타임) 예외를 사용하자 체크 예외들은 바깥으로 던져야 하는데 이 과정에서 의존 관계 문제 발생 실무에서 발생하는 대부분의 예외는 복구 불가능한 시스템 예외 (애플리케이션 단에서 처리 불가) 의존 관계 문제 컨트롤러, 서비스는 본인이 처리할 수 없어도 throws를 선언해 예외를 던져야 함 컨트롤러, 서비스가 해당 체크 예외에 의존하게 되어 구현 기술 변경 시 OCP 위반 예를 들어, DB 접근 기술을 변경한다면 예외를 포함한 컨트롤러, 서비스 코드를 수정 수 많은 체크 예외를 일일이 명시해 던지는 것도 부담 런타임 예외를 사용하면 처리할 수 없는 예외를 별도 선언 없이 그냥 두면 됨 의존성 발생 X -> 기술 변경이 있어도 컨트롤러, 서비스 코드 변경 X -> OCP 준수 대부분의 최근 라이브러리는 런타임 예외를 기본으로 제공 (스프링, JPA…) 런타임 예외는 놓칠 수 있기 때문에 문서화가 중요 (혹은 명시적으로 코드에 throws 남기기) 처리할 수 없는 예외들은 한 곳에서 공통처리 서블릿 오류 페이지, 스프링 MVC ControllerAdvice 예외 공통 처리 고객: 오류 페이지 내부 개발자: 별도 로그, 슬랙, 문자, 메일을 통해 개발자가 빠르게 인지 API는 상태코드 500 응답 예시 코드 public class Main { public static void main(String[] args) { NetworkService networkService = new NetworkService(); try { networkService.sendMessage(); } catch (Exception e) { // 모든 예외를 잡아서 처리 exceptionHandler(e); } } //공통 예외 처리 private static void exceptionHandler(Exception e) { //공통 처리 System.out.println("사용자 메시지: 죄송합니다. 알 수 없는 문제가 발생했습니다."); System.out.println("==개발자용 디버깅 메시지=="); e.printStackTrace(System.out); // 스택 트레이스 출력 //e.printStackTrace(); // System.err에 스택 트레이스 출력 //실무에서는 보통 Slf4j 사용해 로그를 콘솔 출력 + 파일로 저장 //e.printStackTrace는 콘솔에만 출력하므로 사용 X //필요하면 예외 별로 별도의 추가 처리 가능 if (e instanceof SendException sendEx) { System.out.println("[전송 오류] 전송 데이터: " + sendEx.getSendData()); } } } 체크 예외는 비즈니스 로직상 의도적으로 던지는 예외에만 사용 매우 심각한 문제는 개발자가 실수로 예외를 놓치면 안된다고 판단할 수 있음 체크 예외 예시 (무조건 해야하는 건 아님) 계좌 이체 실패 예외 결제시 포인트 부족 예외 로그인 ID, PW 불일치 예외 Exception을 던지지 말자 코드가 깔끔해지는 것 같지만, 모든 체크 예외를 다 던져 버려서 중요한 체크 예외를 놓침 꼭 필요한 경우가 아니면 Exception 자체를 밖으로 던지는 것은 좋은 방법이 아님 스택 트레이스를 남기자 로그 남기기 log.info("예외 처리, message={}", e.getMessage(), e); 로그의 마지막 인수에 예외 객체 전달하면 로그에 스택 트레이스를 출력 예외를 전환할 때는 반드시 기존 예외를 포함하자 throw new RuntimeSQLException(e); - 기존 예외 e 포함 덕분에 기존 예외와 스택 트레이스까지 확인 가능 포함하지 않으면 실제 DB에서 발생한 근본적인 원인을 확인할 수 없는 심각한 문제 발생 예외를 계속 던지면 벌어지는 상황 자바 main() 쓰레드의 경우 예외 로그를 출력하면서 시스템이 종료 웹 애플리케이션의 경우 WAS가 예외를 받아 처리하고 개발자가 지정한 오류 페이지 보여줌 (예외 하나로 시스템이 종료되면 안됨) 사용자 예외 만들기 Exception을 상속 받으면 체크 예외 RuntimeException을 상속 받으면 언체크 예외 오류 메시지 보관하기 생성자를 통해 오류 메시지를 보관할 것 (예외가 제공하는 기본 기능) super(message)로 전달한 메시지는 Throwable의 detailMessage에 보관됨 getMessage()로 조회 가능 public class MyCheckedException extends Exception { public MyCheckedException(String message) { super(message); } } 적당한 예외 계층화하기 (너무 많아도 문제) 상속을 사용해 예외를 계층화하면 보다 세밀한 예외 처리 가능 e.g. NetworkClientException (부모) ConnectException (자식, 내부 연결 시도 address 보관) SendException (자식, 내부 전송 시도 데이터 sendData 보관) 각각의 하위 예외에 고유 기능을 만들어 활용 가능 e.g. e.getAddress(), e.getSendData() 부모 예외를 잡아 자식까지 한 번에 처리하거나 특정 하위 예외만 잡아 처리 가능 중요한 특정 하위 예외만 메시지를 명확히 남기고 나머지는 공통 처리 가능 e.g. [연결 오류] 주소: ... (하위 예외) [네트워크 오류] 메시지: ... (부모 예외) [알 수 없는 오류] 메시지: ... (그 외 예외 공통 처리) 예외 처리 발전 과정 예시 (e.g. NetworkClient) 반환 값(문자열)으로 예외 처리 분기 처리 및 return으로 네트워크 연결 및 해제, 데이터 전송 관리 등이 가능 가장 중요한 정상 흐름이 한눈에 들어오지 않음 (정상 흐름과 예외 흐름 분리 X, 가독성 감소) 예외 처리 메커니즘 사용 (try ~ catch ~ finally) 성공 여부를 반환값이 아닌 메서드 정상 종료 여부로 판단 정상 흐름과 예외 흐름을 명확히 분리해 가독성 상승 (try 블록, catch 블록) 반드시 실행되어야 하는 코드를 안전하게 호출하도록 보장 (finally) finally가 없으면 catch에서 잡지 못한 예외가 발생할 때 문제가 생김 외부 자원 해제 등에 편리 finally finally 블록은 어떤 경우라도 반드시 호출된다. 주로 try에서 사용한 자원을 해제할 때 사용한다. 예외를 직접 잡을 일이 없다면, try ~ finally만 사용하는 것도 가능하다. 정상 흐름 (try) -> finally 예외 잡음 (catch) -> finally 예외 던짐 -> finally (finally 블록 끝난 이후 예외가 밖으로 던져짐) 자원 해제 외부 리소스는 사용 후 반드시 연결을 해제하고 자원을 반납해야 메모리 고갈을 피할 수 있다. (네트워크 연결 자원, DB 연결 자원…) 자바는 GC로 JVM 메모리 상 인스턴스들을 자동으로 해제하지만, 외부 연결 같은 자바 외부 자원은 자동으로 해제되지 않는다. 여러 예외 한 번에 잡는 Syntax catch 블록에서 | 키워드를 사용해 예외를 나열할 수 있다. 다만, 이 경우 각 예외들의 공통 부모 기능만 사용할 수 있다. e.g. catch (ConnectException | SendException e) {...} // 이 경우 공통 부모인 NetworkClientException의 기능만 사용 가능 try-with-resources 구문 finally 없이 편리한 외부 자원 해제 지원 사용 방법 외부 자원 클래스에 AutoCloseable 인터페이스를 구현 (implements AutoCloseable) close() 메서드를 오버라이드해 자원 반납 방법 정의 메서드가 예외를 던지지 않으면 인터페이스의 throws Exception은 생략 try-with-resources 구문 사용 try (Resource resource = new Resource()) { // 리소스를 사용하는 코드 } try 괄호 안에 사용할 자원을 명시 e.g. try (NetworkClient client = new NetworkClient(address)) {...} try 블록이 끝나면 자동으로 AutoCloseable.close() 호출해 자원 해제 try 블록만 단독으로도 사용 가능 (catch, finally 없이 사용 가능) 장점 리소스 누수 방지 실수로 finally 블록 혹은 그 내부에 자원 해제 코드를 누락하는 문제 예방 코드 간결성 및 가독성 향상 리소스 스코프 범위 한정 리소스 객체 변수의 스코프를 try 블록으로 한정해 코드 유지보수성 향상 조금 더 빠른 자원 해제 기존에는 catch 이후에 자원을 반납 (try -> catch -> finally) try with resources는 try 블록이 끝나면 즉시 close() 호출 Reference 김영한의 실전 자바 - 중급 1편

Java-Ecosystem · 2024-08-24

자바 중첩 클래스

Java-Ecosystem · 2024-08-17

자바 날짜 시간 라이브러리

날짜 시간 라이브러리의 필요성 날짜 라이브러리는 복잡한 계산을 추상화해 제공하므로, 안정적이고 정확한 개발 가능 자바 8에서 java.time 패키지(JSR-310)를 표준 API(기능의 모음)로 도입 외부 라이브러리였던 Joda-Time의 개발자를 데려와 새로운 자바 표준 API를 함께 정의 이전 문제가 많던 API를 크게 개선 (사용성, 성능, 스레드 안정성, 타임존 처리, 불변 객체 설계 등) 날짜 계산이 어려운 이유 각 달은 28~31일로 다르게 분포 윤년 (Leap Year) 지구가 태양을 한 바퀴 도는 평균 시간은 약 365.2425일 (약 365일 5시간 48분 45초) 우리가 사용하는 그레고리력은 1년이 365일 윤년은 둘의 간극을 매우기 위한 해결책으로 4년마다 하루를 추가 (2월 29일) 100년 단위는 윤년이 아니며 400년 단위는 다시 윤년 일광 절약 시간 (Daylight Saving Time, DST) - 썸머타임 보통 3월 중순~11월 초 태양이 일찍 뜨는 것에 맞춰 1시간 앞당기는 제도 국가나 지역에 따라 적용 여부 및 시작 종료 날짜가 다름 타임존 계산 각각의 타임존은 UTC(세계 협정시)로부터의 시간 차이로 정의 London / UTC / GMT는 세계 시간의 기준이 되는 00:00 시간대 GMT (그리니치 평균시, Greenwich Mean Time) 처음 세계 시간은 영국 런던 그리니치 천문대를 기준으로 만듦 UTC (협정 세계시, Universal Time Coordinated) GMT를 대체하기 위해 도입 (둘은 실질적으로 같은 시간대) 다만, UTC는 원자 시계를 사용해 측정해 보다 정확한 시간 유지 타임존 예시 Europe/London GMT UTC America/New_York -05:00 Asia/Seoul +09:00 자바 날짜 시간 라이브러리 (time) - 클래스 분류표 유의점 모든 날짜 클래스는 불변 -> 변경이 발생하는 경우 새로운 객체를 생성해 반환 초는 나노초 정밀도로 캡처 가능 Year, Month, YearMonth, MonthDay: 자주 사용 X DayOfWeek: 월, 화, 수, 목, 금, 토, 일을 나타내는 Enum (ChronoField) 날짜와 시간 핵심 인터페이스 TemporalAccessor 인터페이스 날짜와 시간을 읽기 위한 기본 인터페이스 날짜와 시간의 2가지 개념 (특정 시점의 시간 & 시간의 간격) Temporal 인터페이스 - 특정시점의 시간 날짜와 시간을 조작하기 위한 기능 추가 제공 상위 인터페이스 덕분에 읽기와 쓰기 모두 지원 구현체 LocalDateTime, LocalDate, LocalTime ZonedDateTime, OffsetDateTime Instant TemporalAmount 인터페이스 - 시간의 간격 특정 날짜 시간 객체에 일정 기간을 더하거나 빼는데 사용 구현체 Period , Duration 시간의 단위와 필드 - 단독 사용 X, 날짜 시간 조회나 조작에 사용 TemporalUnit 인터페이스 - 시간의 단위 날짜와 시간을 측정하는 단위 구현체(Enum): ChronoUnit 시간: NANOS, MICROS, MILLIS, SECONDS, MINUTES, HOURS 날짜: DAYS, WEEKS, MONTHS, YEARS, DECADES, CENTURIES, MILLENNIA 기타: ERAS, FOREVER 주요 메서드 between(Temporal, Temporal) 두 Temporal 객체 사이의 시간을 현재 ChronoUnit 단위로 측정하여 반환 e.g. LocalTime lt1 = LocalTime.of(1, 10, 0); LocalTime lt2 = LocalTime.of(1, 20, 0); long secondsBetween = ChronoUnit.SECONDS.between(lt1, lt2); long minutesBetween = ChronoUnit.MINUTES.between(lt1, lt2); getDuration() 현재 ChronoUnit의 기간을 Duration 객체로 반환 e.g. ChronoUnit.HOURS.getDuration().getSeconds() //3600 ChronoUnit.DAYS.getDuration().getSeconds() //86400 TemporalField 인터페이스 - 시간의 각 필드 날짜와 시간의 특정 부분을 나타냄 (연도, 월, 일, 시간, 분) 예를 들어, 일(day)은 31보다 클 수 없는 것처럼 범위가 생김 구현체(Enum): ChronoField 연도: ERA, YEAR_OF_ERA, YEAR, EPOCH_DAY 월 MONTH_OF_YEAR: 월 (1월 = 1) 주 및 일 DAY_OF_MONTH: 월의 일 (1일 = 1) DAY_OF_WEEK: 요일 (월요일 = 1) DAY_OF_YEAR: 연의 일 (1월 1일 = 1) 시간 HOUR_OF_DAY: 시간 (0-23) HOUR_OF_AMPM: 오전/오후 시간 (0-11) CLOCK_HOUR_OF_DAY: 시계 시간 (1-24) CLOCK_HOUR_OF_AMPM: 오전/오후 시계 시간 (1-12) MINUTE_OF_HOUR: 분 (0-59) SECOND_OF_MINUTE: 초 (0-59) MILLI_OF_SECOND: 초의 밀리초 (0-999) MICRO_OF_SECOND: 초의 마이크로초 (0-999,999) NANO_OF_SECOND: 초의 나노초 (0-999,999,999) 기타 AMPM_OF_DAY: 하루의 AM/PM 부분 주요 메서드 range() 필드 값의 유효 범위를 ValueRange 객체로 반환 (최소값과 최대값을 제공) e.g. ChronoField.MONTH_OF_YEAR.range() //1 - 12 ChronoField.DAY_OF_MONTH.range() //1 - 28/31 Temporal - 특정 시점의 시간 기본 날짜 시간 표현 (LocalXxx) 특정 지역의 날짜와 시간만 고려할 때 사용 (타임존 적용 X, 시간대 고려 X) 국내 서비스만 고려할 때 권장 종류 LocalDate: 날짜만 표현 (년, 월, 일) 예) 2013-11-21 LocalTime: 시간만 표현 (시, 분, 초) 예) 08:20:30.213 밀리초, 나노초 단위도 포함 가능 LocalDateTime: LocalDate + LocalTime 예) 2013-11-21T08:20:30.213 클래스 내부에 LocalDate와 LocalTime을 필드로 가지고 있음 public class LocalDateTime { private final LocalDate date; private final LocalTime time; ... } 주요 메서드 공통 메서드 생성 now(): 현재 시간 기준으로 생성 of(...): 특정 날짜를 기준으로 생성 계산 dt.plusXxx(): 특정 날짜 시간 단위를 더함 e.g. plusYears(1), plusDays(10), plusSeconds(30) LocalDatetime 날짜와 시간 분리 dt.toLocalDate(): 주어진 LocalDateTime에서 날짜만 반환 dt.toLocalTime(): 주어진 LocalDateTime에서 시간만 반환 날짜와 시간 합체 of(...): 날짜와 시간을 묶어서 LocalDateTime으로 만들기 e.g. LocalDateTime.of(localDate, localTime) 비교 dt.isBefore(): 현재 날짜시간이 지정 날짜시간보다 이전이라면 true 를 반환 dt.isAfter(): 현재 날짜시간이 지정 날짜시간보다 이후라면 true 를 반환 dt.isEqual(): 현재 날짜시간과 지정 날짜시간 시간적으로 동일하면 true 를 반환 isEqual() 객체가 다르고 타임존이 달라도 시간적으로 같으면 true e.g. 서울의 9시와 UTC의 0시는 시간적으로 동일 equals() 객체 타입, 타임존 등등 내부 데이터의 모든 구성요소가 같아야 true e.g. 서울의 9시와 UTC의 0시는 타임존이 다르므로 false 시간대 적용 날짜 시간 표현 (ZonedDateTime, OffsetDateTime) 글로벌 서비스 개발 시에만 사용 (그러지 않으면 거의 사용 X) 용어 타임존(Time Zone) 오프셋과 일광 절약 시간제에 대한 정보 담김 -> 타임존을 알면 일광 절약 시간제를 알 수 있음 예) Asia/Seoul 오프셋(Offset) UTC로 부터의 시간대 차이 예) +9:00 종류 ZoneId 자바가 제공하는 타임존 클래스 내부에 오프셋과 일광 절약 시간제 정보 포함 ZonedDateTime 시간대를 표현하는 타임존이 포함 (LocalDateTime + ZoneId) 일광 절약 시간제 적용 실제 사용 날짜와 시간 정보 표현에 적합 (비행기 시간, 회의 시간, 일상 시간 표현…) 예) 2013-11-21T08:20:30.213+9:00[Asia/Seoul] 클래스 내부에 LocalDatetime, ZoneId, ZoneOffset을 필드로 가지고 있음 public class ZonedDateTime { private final LocalDateTime dateTime; private final ZoneOffset offset; private final ZoneId zone; ... } OffsetDateTime 타임존은 없고, 고정된 오프셋만 포함 (LocalDateTime + ZoneOffset) 일광 절약 시간제 적용 X 시간대 변환 없이 로그를 기록하고 처리할 때 적합 로그는 순차적으로 쌓여야 함, 썸머타임 적용으로 1시간 당겨지는 상황 있으면 안됨 예) 2013-11-21T08:20:30.213+9:00 클래스 내부에 LocalDatetime, ZoneOffset을 필드로 가지고 있음 public class OffsetDateTime { private final LocalDateTime dateTime; private final ZoneOffset offset; ... } 주요 메서드 공통 메서드 생성 now(): 현재 시간 기준으로 생성 (ZoneId는 현재 시스템을 따름) of(...): 특정 날짜를 기준으로 생성 ZonedDatetime of(...) 사용법 단순 생성 ZonedDateTime zdt = ZonedDateTime.of(2030, 1, 1, 13, 30, 50, 0, ZoneId.of("Asia/Seoul")); LocalDatetime + ZoneId로 생성하기 LocalDateTime ldt = LocalDateTime.of(2030, 1, 1, 13, 30, 50); ZonedDateTime zdt = ZonedDateTime.of(ldt, ZoneId.of("Asia/Seoul")); 타임존 변경하기 zdt.withZoneSameInstant(): 입력한 타임존으로 변경 e.g. zdt.withZoneSameInstant(ZoneId.of("UTC")) OffsetDatetime of(...) 사용법 LocalDatetime + ZoneOffset로 생성하기 LocalDateTime ldt = LocalDateTime.of(2030, 1, 1, 13, 30, 50); OffsetDateTime odt = OffsetDateTime.of(ldt, ZoneOffset.of("+01:00")); 이외 ZoneId getAvailableZoneIds(): 이용 가능한 모든 ZoneId 반환 systemDefault(): 시스템이 사용하는 기본 ZoneId 반환 of(...): 타임존을 직접 제공해서 ZoneId로 변환 e.g. ZoneId.of("Asia/Seoul") 기계 중심의 시간 (Instant) UTC를 기준으로 하는 시간의 한 지점 1970년 1월 1일 0시 0분 0초(UTC)를 기준으로 경과한 시간으로 계산 (초 데이터) 클래스 내부에 초 데이터를 필드로 가짐 (나노초 정밀도) public class Instant { private final long seconds; private final int nanos; ... } 일반적으로 LocalDateTime , ZonedDateTime를 사용하고 Instant는 특별한 경우에 사용 기준점이 명확하나(UTC), 사람이 읽기 어렵고 초 단위 간단한 연산만 가능 사용 예 로그 기록, 트랜잭션 타임스탬프, 서버 간 시간 동기화 등 전 세계적으로 일관된 시점 표현 시 지속 시간 계산 등 시간대 변화 없는 순수한 시간 흐름만을 다룰 때 DB에 날짜 시간 저장하거나 다른 시스템과 날짜 시간 정보를 교환할 때 주요 메서드 생성 now() UTC를 기준 현재 시간의 Instant 를 생성 from() 다른 타입의 날짜와 시간을 기준으로 Instant 를 생성 LocalDateTime 사용 불가 (Instant 는 UTC 기준이어서 시간대 정보가 필요) e.g. ZonedDateTime zdt = ZonedDateTime.now(); Instant from = Instant.from(zdt); ofEpochSecond() 에포크 시간을 기준으로 Instant 를 생성 ofEpochSecond(0) -> 에포크 시간인 1970년 1월 1일 0시 0분 0초로 생성 ofEpochSecond(30) -> 1970/1/1/0/0/30 계산 plusSeconds() : 초, 밀리초, 나노초 정도만 더하는 간단한 메서드 조회 getEpochSecond() : UTC 1970년 1월 1일 0시 0분 0초를 기준으로 흐른 초를 반환 Epoch 시간 Epoch time(에포크 시간) 또는 Unix timestamp는 컴퓨터 시스템에서 시간을 나타내는 방법 중 하나이다. 1970년 1월 1일 00:00:00 UTC부터 현재까지 경과된 시간을 초 단위로 표현한 것이다. 즉, 시간대에 영향을 받지 않는 절대적인 시간 표현 방식이다. Instant는 Epoch 시간을 다루는 클래스이다. TemporalAmount - 시간의 간격 (기간, 시간의 양, amount of time) 년, 월, 일 단위 표현 (Period) 클래스 내부에 년, 월, 일을 필드로 가짐 public class Period { private final int years; private final int months; private final int days; } 주요 메서드 생성 of() : 특정 기간을 지정해서 Period 를 생성 of(년, 월, 일) ofDays() ofMonths() ofYears() 계산 더하기 특정 날짜 인스턴스의 plus() 메서드를 사용해 기간을 더할 수 있음 e.g. LocalDate currentDate = LocalDate.of(2030, 1, 1); Period period = Period.ofDays(10); LocalDate plusDate = currentDate.plus(period); between(): 기간 차이 구하기 (Period 반환) LocalDate startDate = LocalDate.of(2023, 1, 1); LocalDate endDate = LocalDate.of(2023, 4, 2); Period between = Period.between(startDate, endDate); //Period 반환 조회 getYears(), getMonths(), getDays() 시, 분, 초(나노초) 단위 표현 (Duration) 클래스 내부에 초 데이터만 필드로 가짐 내부에서 초를 기반으로 시, 분, 초를 계산해서 사용 public class Duration { private final long seconds; private final int nanos; } 주요 메서드 생성 of() : 특정 시간을 지정해서 Duration 를 생성 of(지정) ofSeconds() ofMinutes() ofHours() 계산 더하기 특정 시간 인스턴스의 plus() 메서드를 사용해 시간을 더할 수 있음 e.g. LocalTime lt = LocalTime.of(1, 0); Duration duration = Duration.ofMinutes(30); LocalTime plusTime = lt.plus(duration); between(): 시간 차이 구하기 (Duration 반환) LocalTime start = LocalTime.of(9, 0); LocalTime end = LocalTime.of(10, 0); Duration between = Duration.between(start, end); //Duration 반환 조회 get은 바로 가져오는 느낌, to는 계산을 하는 느낌 (Duration은 내부에 초 데이터만 보유) toHours(), toMinutes() getSeconds(), getNano() 일반적인 x시간 x분을 출력할 때는 toHoursPart() + toMinutesPart() 조합 사용 toHoursPart(), toMinutesPart(), toSecondsPart() 날짜와 시간 조회 및 조작 일관성 있는 시간 조회 및 조작 기능 제공 (인터페이스 설계가 잘되어 있음) 불변 객체이므로 메서드 체이닝 가능 기본 규칙 조회 방법 편의 메서드 사용 (가독성을 위해 권장) 자주 사용하는 조회 필드는 간단한 편의 메서드 제공 getYear(), getMonthValue(), getDayOfMonth(), getHour(), getMinute(), getSecond(), getDayOfWeek() TemporalAccessor.get(TemporalField field) ChronoField 인수로 전달해, 날짜 시간 객체에서 원하는 단위로 조회 가능 get(ChronoField.YEAR), get(ChronoField.MONTH_OF_YEAR), get(ChronoField.DAY_OF_MONTH), get(ChronoField.HOUR_OF_DAY), get(ChronoField.MINUTE_OF_HOUR), get(ChronoField.SECOND_OF_MINUTE), get(ChronoField.DAY_OF_WEEK) 편의 메서드에 없는 경우 사용 조작 방법 편의 메서드 사용 자주 사용하는 메서드는 간단한 편의 메서드 제공 plus -> plusXxx, minus -> minusXxx Temporal plus(TemporalAmount amount) Period, Duration 인수로 전달해 조작 가능 Temporal plus(long amountToAdd, TemporalUnit unit) 시간의 양과 ChronoUnit 인수로 전달해, 특정 시점의 시간을 조작 가능 isSupported() - TemporalAccessor & Temporal 인터페이스 현재 타입에서 특정 시간 단위나 필드를 사용할 수 있는지 확인 e.g. LocalDate에는 시, 분, 초 단위 관련 조회 및 조작을 할 수 없음 LocalDate now = LocalDate.now(); boolean supported = now.isSupported(ChronoField.SECOND_OF_MINUTE);//false if (supported) { int minute = now.get(ChronoField.SECOND_OF_MINUTE); } 기간 차이 구하기 남은 기간 Period, Duration의 between() e.g. Period period = Period.between(startDate, endDate); 년: period.getYears() / 월: period.getMonths() / 일: period.getDays() 디데이 ChronoUnit의 between(Temporal, Temporal) e.g. long daysBetween = ChronoUnit.DAYS.between(startDate, endDate); with() 복잡한 날짜 계산에 적합 날짜와 시간의 특정 필드 값만 변경하는 것이 가능 방법 편의 메서드 자주 사용하는 메서드는 간단한 편의 메서드 제공 dt.with(ChronoField.YEAR, 2020) -> dt.withYear(2020) TemporalAdjusters 사용 TemporalAdjuster 인터페이스의 구현체 묶음 (자바가 만들어 둠) 더욱 복잡한 날짜 계산 가능 e.g dt.with(TemporalAdjusters.next(DayOfWeek.FRIDAY)) 다음주 금요일 구하기 dt.with(TemporalAdjusters.lastInMonth(DayOfWeek.SUNDAY)) 이번 달의 마지막 일요일 구하기 Temporal with(TemporalField field, long newValue) 단순한 날짜만 변경 가능 e.g. dt.with(ChronoField.YEAR, 2020) 날짜와 시간 문자열 파싱과 포멧팅 포멧팅과 파싱 포멧팅: Date -> String 파싱: String -> Date DateTimeFormatter 날짜와 시간 포멧팅 및 파싱에 사용 포멧팅: ofPattern() LocalDate date = LocalDate.of(2024, 12, 31); DateTimeFormatter formatter = DateTimeFormatter.ofPattern("yyyy년 MM월 dd 일"); String formattedDate = date.format(formatter); //2024년 12월 31일 파싱: 특정 날짜 객체의 parse() LocalDate date = LocalDate.of(2024, 12, 31); String input = "2030년 01월 01일"; DateTimeFormatter formatter = DateTimeFormatter.ofPattern("yyyy년 MM월 dd 일"); LocalDate parsedDate = LocalDate.parse(input, formatter); 자주 쓰이는 패턴 y: 연대의 연도 M: 연중 월 d: 월의 일수 H: 24시간제 시(0-23) m: 분 s: 초 패턴 예시 “yyyy년 MM월 dd 일” “yyyy-MM-dd HH:mm:ss” ISO 8601 날짜와 시간의 표준 출력. Reference 김영한의 실전 자바 - 중급 1편

Java-Ecosystem · 2024-08-06

자바 lang 패키지

Java-Ecosystem · 2024-08-01

스프링 파일 업로드

HTML Form 전송 방식 차이 application/x-www-form-urlencoded HTML 폼 기본 전송 방식 폼 태그에 enctype 옵션을 주지 않을 시 자동 지정 multipart/form-data 여러 데이터 형식을 함께 보내기 위한 Form 데이터 전송 방식 (HTTP 제공) 파일은 문자가 아닌 바이너리 타입으로 전송 필요 각각의 항목을 구분해 한번에 전송 e.g. 폼 데이터 전송 시 문자와 바이너리를 동시 전송 문자: 이름, 나이… 파일: 첨부파일 폼 태그 -> enctype="multipart/form-data" 서블릿 파일 업로드 HttpServletRequest request.getParameter(...) 요청 파라미터 접근 request.getParts() multipart/form-data 전송 방식에서 각각 나누어진 부분을 받아서 확인 개별 Part 메서드 part.getSubmittedFileName() : 클라이언트가 전달한 파일명 part.getInputStream(): Part의 전송 데이터를 읽기 (Body) part.write(fullPath): Part를 통해 전송된 데이터를 지정 경로에 저장 스프링 파일 업로드 업로드하는 HTML Form의 name에 맞추어 @RequestParam 을 적용하면 됨 @RequestParam String itemName @RequestParam MultipartFile file MultipartFile 인터페이스 제공 메서드 file.getOriginalFilename() : 업로드 파일 명 file.transferTo(...) : 파일 저장 서블릿에 비해 HttpServletRequest를 사용 X 파일 부분만 구분하기도 편리 예시 코드 @Slf4j @Controller @RequestMapping("/spring") public class SpringUploadController { @Value("${file.dir}") private String fileDir; @GetMapping("/upload") public String newFile() { return "upload-form"; } @PostMapping("/upload") public String saveFile(@RequestParam String itemName, @RequestParam MultipartFile file, HttpServletRequest request) throws IOException { log.info("request={}", request); log.info("itemName={}", itemName); log.info("multipartFile={}", file); if (!file.isEmpty()) { String fullPath = fileDir + file.getOriginalFilename(); log.info("파일 저장 fullPath={}", fullPath); file.transferTo(new File(fullPath)); } return "upload-form"; } } 멀티파트 관련 사용 옵션 (application.properties) 실제 파일 저장 경로 지정 file.dir=파일 업로드 경로 e.g. /Users/lucian/study/file/ 해당 경로에 반드시 실제 폴더 만들어두기 지정 파일 경로는 컨트롤러의 멤버 변수에 주입해 사용 가능 //application.properties에서 설정한 파일 경로 주입 @Value("${file.dir}") private String fileDir; 업로드 사이즈 제한 //파일 하나의 최대 사이즈 (기본 1MB) spring.servlet.multipart.max-file-size=1MB //멀티 파트 요청 하나의 여러 파일 전체 합 (기본 10MB) spring.servlet.multipart.max-request-size=10MB 큰 파일 무제한 업로드를 예방하고 업로드 사이즈 제한 가능 사이즈를 넘길 시 예외 발생 (SizeLimitExceededException) 서블릿 컨테이너 멀티파트 관련 처리 옵션 spring.servlet.multipart.enabled (기본 true) false: 멀티파트 처리 안하기 결과 request=org.apache.catalina.connector.RequestFacade@xxx itemName=null parts=[] true: 멀티파트 처리하기 결과 request=org.springframework.web.multipart.support.StandardMultipartHttpServletRequest itemName=Spring parts=[ApplicationPart1, ApplicationPart2] true일 시, 스프링 DispatcherServlet의 MultipartResolver를 실행 MultipartResolver는 멀티파트 요청이 온 경우 HttpServletRequest -> MultipartHttpServletRequest 변환 스프링 기본 멀티파트 리졸버는 StandardMultipartHttpServletRequest 반환 MultipartHttpServletRequest HttpServletRequest의 자식 인터페이스 멀티파트 관련 추가 기능 제공 StandardMultipartHttpServletRequest MultipartHttpServletRequest 인터페이스 구현체 실제 파일 업로드 구현 시 주의사항 고객이 업로드한 파일명과 서버 내부 관리 파일명은 다르게 할 것 서로 다른 고객이 같은 파일 이름을 업로드하면 기존 파일과 충돌 발생 예시 구현 업로드 파일 정보 @Data public class UploadFile { private String uploadFileName; private String storeFileName; public UploadFile(String uploadFileName, String storeFileName) { this.uploadFileName = uploadFileName; this.storeFileName = storeFileName; } } 상품 도메인 객체 @Data public class Item { private Long id; private String itemName; private UploadFile attachFile; private List<UploadFile> imageFiles; } 파일 저장 객체 구현하기 멀티파트 파일을 서버에 저장하는 역할 파일은 보통 로컬 스토리지나 S3에 저장하고 DB에는 해당 경로만 저장 (DB에 파일 자체 저장 X) 예시 구현 @Component public class FileStore { @Value("${file.dir}") private String fileDir; public String getFullPath(String filename) { return fileDir + filename; } public List<UploadFile> storeFiles(List<MultipartFile> multipartFiles) throws IOException { List<UploadFile> storeFileResult = new ArrayList<>(); for (MultipartFile multipartFile : multipartFiles) { if (!multipartFile.isEmpty()) { storeFileResult.add(storeFile(multipartFile)); } } return storeFileResult; } public UploadFile storeFile(MultipartFile multipartFile) throws IOException { if (multipartFile.isEmpty()) { return null; } String originalFilename = multipartFile.getOriginalFilename(); String storeFileName = createStoreFileName(originalFilename); multipartFile.transferTo(new File(getFullPath(storeFileName))); return new UploadFile(originalFilename, storeFileName); } //서버 내부 관리 파일명 생성 (UUID 사용해 충돌 방지) private String createStoreFileName(String originalFilename) { String ext = extractExt(originalFilename); String uuid = UUID.randomUUID().toString(); return uuid + "." + ext; } //확장자 추출 함수 private String extractExt(String originalFilename) { int pos = originalFilename.lastIndexOf("."); return originalFilename.substring(pos + 1); } } 파일 저장 폼 전송 객체 예시 @Data public class ItemForm { private Long itemId; private String itemName; private List<MultipartFile> imageFiles; //이미지 다중 업로드 private MultipartFile attachFile; } 파일 저장 뷰 예시 다중 파일 업로드는 <input> 태그에 multiple="multiple" 옵션 지정 ItemForm의 List<MultipartFile> imageFiles을 통해 여러 이미지 파일 받을 수 있음 <!DOCTYPE HTML> <html xmlns:th="http://www.thymeleaf.org"> <head> <meta charset="utf-8"> </head> <body> <div class="container"> <div class="py-5 text-center"> <h2>상품 등록</h2> </div> <form th:action method="post" enctype="multipart/form-data"> <ul> <li>상품명 <input type="text" name="itemName"></li> <li>첨부파일<input type="file" name="attachFile" ></li> <li>이미지 파일들<input type="file" multiple="multiple" name="imageFiles" ></li> </ul> <input type="submit"/> </form> </div>  </body> </html> 파일 조회 및 다운로드 예시 이미지 조회 UrlResource로 이미지 파일을 읽어서 @ResponseBody로 이미지 바이너리 반환 파일 다운로드 Content-Disposition 헤더에 attachment; filename="업로드 파일명" 주기 파일 다운로드 시에는 고객이 업로드한 파일명으로 다운로드하는게 좋음 (UTF_8 인코딩) UrlResource로 파일을 읽어서 헤더와 바디를 ResponseEntity<Resource> 반환 예시 구현 @Slf4j @Controller @RequiredArgsConstructor public class ItemController { private final ItemRepository itemRepository; private final FileStore fileStore; @GetMapping("/items/new") public String newItem(@ModelAttribute ItemForm form) { return "item-form"; } @PostMapping("/items/new") public String saveItem(@ModelAttribute ItemForm form, RedirectAttributes redirectAttributes) throws IOException { UploadFile attachFile = fileStore.storeFile(form.getAttachFile()); List<UploadFile> storeImageFiles = fileStore.storeFiles(form.getImageFiles()); //데이터베이스에 저장 Item item = new Item(); item.setItemName(form.getItemName()); item.setAttachFile(attachFile); item.setImageFiles(storeImageFiles); itemRepository.save(item); redirectAttributes.addAttribute("itemId", item.getId()); return "redirect:/items/{itemId}"; } @GetMapping("/items/{id}") public String items(@PathVariable Long id, Model model) { Item item = itemRepository.findById(id); model.addAttribute("item", item); return "item-view"; } @ResponseBody @GetMapping("/images/{filename}") public Resource downloadImage(@PathVariable String filename) throws MalformedURLException { return new UrlResource("file:" + fileStore.getFullPath(filename)); } @GetMapping("/attach/{itemId}") public ResponseEntity<Resource> downloadAttach(@PathVariable Long itemId) throws MalformedURLException { Item item = itemRepository.findById(itemId); String storeFileName = item.getAttachFile().getStoreFileName(); String uploadFileName = item.getAttachFile().getUploadFileName(); UrlResource resource = new UrlResource("file:" + fileStore.getFullPath(storeFileName)); log.info("uploadFileName={}", uploadFileName); String encodedUploadFileName = UriUtils.encode(uploadFileName, StandardCharsets.UTF_8); String contentDisposition = "attachment; filename=\"" + encodedUploadFileName + "\""; return ResponseEntity.ok() .header(HttpHeaders.CONTENT_DISPOSITION, contentDisposition) .body(resource); } } Reference 스프링 MVC 2편 - 백엔드 웹 개발 활용 기술

Java-Ecosystem · 2024-07-28

스프링 타입 컨버터

스프링 Converter HTTP 요청 데이터는 문자로 처리됨 다만, 파라미터를 원하는 타입으로 지정하면 스프링이 자동으로 타입 변환 개발자는 직접 타입 변환할 필요 없이 원하는 타입으로 편리하게 전달 받아 사용 예시 @RequestParam, @ModelAttribute, @PathVariable … (스프링 MVC 요청 파라미터) @Value 등으로 YML 정보 읽기 XML에 넣은 스프링 빈 정보 변환 뷰 렌더링 시 컨버터 인터페이스 package org.springframework.core.convert.converter; public interface Converter<S, T> { T convert(S source); } 스프링은 확장 가능한 컨버터 인터페이스 지원 org.springframework.core.convert.converter.Converter 개발자는 스프링에 추가적인 타입 변환이 필요하면 인터페이스를 구현해 등록 Converter와 PropertyEditor 과거에는 PropertyEditor로 타입 변환했으나 동시성 문제가 있어서 잘 사용하지 않는다. 지금은 기능 확장 시 Converter를 사용한다. 스프링이 제공하는 다양한 컨버터 Converter: 기본 타입 컨버터 ConverterFactory: 전체 클래스 계층 구조가 필요할 때 GenericConverter: 정교한 구현, 대상 필드의 애노테이션 정보 사용 가능 ConditionalGenericConverter: 특정 조건이 참인 경우에만 실행 스프링은 문자, 숫자, 불린, Enum 등 일반적인 타입에 대한 대부분의 인터페이스 구현체들을 제공한다. ConversionService 스프링은 개별 컨버터를 모아서 묶어두고 편리하게 사용할 수 있도록 제공 스프링 내부에서도 ConversionService를 사용해 타입 변환 e.g @RequestParam RequestParamMethodArgumentResolver에서 ConversionService 사용해 타입 변환 뷰 템플릿도 컨버젼 서비스 적용 가능 (타임 리프 문법: ${{...}}) ConversionService 인터페이스 public interface ConversionService { boolean canConvert(@Nullable Class<?> sourceType, Class<?> targetType); boolean canConvert(@Nullable TypeDescriptor sourceType, TypeDescriptor targetType); <T> T convert(@Nullable Object source, Class<T> targetType); Object convert(@Nullable Object source, @Nullable TypeDescriptor sourceType, TypeDescriptor targetType); } canConvert: 컨버팅이 가능한지 체크 convert: 실제 컨버팅 수행 ConversionService는 2가지 이점 제공 등록과 사용 분리 컨버터 등록 입장: 타입 컨버터를 명확히 알아야 함 컨버터 사용 입장: 컨버전 서비스 인터페이스만 의존, 구체적인 타입 컨버터 몰라도 됨 인터페이스 분리 원칙 적용 (ISP) DefaultConversionService 구현체는 두 인터페이스를 구현 ConversionService: 컨버터 사용에 초점 ConverterRegistry: 컨버터 등록에 초점 ConversionService 인터페이스를 사용하는 클라이언트는 꼭 필요한 메서드만 알게 됨 메시지 컨버터와 컨버전 서비스 HttpMessageConverter에는 컨버전 서비스가 적용되지 않는다. 메시지 컨버터는 Jackson 라이브러리를 사용해 HTTP 메시지 바디 내용을 객체로 변환하거나 객체를 HTTP 메시지 바디에 입력한다. 따라서, JSON 결과로 만들어지는 숫자나 날짜 포멧을 변경하고 싶으면, Jackson 라이브러리가 제공하는 설정을 통해 지정해야 한다. (Jackson Data Format 같은 키워드로 검색 필요) 참고로, 컨버전 서비스는 @RequestParam , @ModelAttribute , @PathVariable , 뷰 템플릿 등에서 사용할 수 있다. Formatter 일반적인 웹 애플리케이션 환경에서의 타입 변환 (개발자) 문자 -> 객체 (다른 타입) 객체 (다른 타입) -> 문자 Formatter는 문자에 특화한 Converter의 특별한 버전 Formatter: 문자 특화 + 현지화(Locale) Converter: 범용 (객체 -> 객체) Formatter 인터페이스 public interface Printer<T> { String print(T object, Locale locale); } public interface Parser<T> { T parse(String text, Locale locale) throws ParseException; } public interface Formatter<T> extends Printer<T>, Parser<T> { } String print(T object, Locale locale) : 객체를 문자로 변경 T parse(String text, Locale locale) : 문자를 객체로 변경 스프링 Formatter 스프링은 용도에 따라 다양한 방식의 포멧터를 제공한다. Formatter: 포멧터 AnnotationFormatterFactory: 필드 타입 혹은 애노테이션 정보를 활용할 수 있는 포멧터 FormattingConversionService 포멧터를 지원하는 컨버전 서비스 포멧터도 특별한 컨버터일 뿐 내부에서 어댑터 패턴을 사용해 Formatter가 Converter처럼 동작하도록 지원 컨버터 & 포멧터를 모두 등록 가능 FormattingConversionService 는 ConversionService 관련 기능을 상속 받음 DefaultFormattingConversionService 구현체: 기본적인 통화, 숫자 기본 포멧터를 추가해 제공 커스텀Converter 및 Formatter 등록 @Configuration public class WebConfig implements WebMvcConfigurer { @Override public void addFormatters(FormatterRegistry registry) { //컨버터 추가 registry.addConverter(new StringToIpPortConverter()); registry.addConverter(new IpPortToStringConverter()); //포멧터 추가 registry.addFormatter(new MyNumberFormatter()); } } 등록 방법은 다르지만 컨버전 서비스를 통해 컨버터와 포멧터를 일관성 있게 사용 가능 addFormatters() 오버라이딩 -> 스프링 내부 ConversionService에 컨버터 자동 등록 addConverter(): 컨버터 추가 addFormatter(): 포멧터 추가 우선 순위 스프링 기본 컨버터보다 추가한 컨버터가 높은 우선순위 포멧터보다 컨버터가 높은 우선 순위 스프링 기본 포멧터 스프링은 자바 기본 타입들에 대한 수많은 포멧터를 기본 제공 애노테이션 기반 포멧터도 제공 덕분에 객체에 각 필드마다 다른 형식으로 포멧 지정 가능 종류 @NumberFormat 숫자 관련 형식 지정 NumberFormatAnnotationFormatterFactory @DateTimeFormat 날짜 관련 형식 지정 Jsr310DateTimeFormatAnnotationFormatterFactory 예시 코드 @Controller public class FormatterController { @GetMapping("/formatter/edit") public String formatterForm(Model model) { Form form = new Form(); form.setNumber(10000); form.setLocalDateTime(LocalDateTime.now()); model.addAttribute("form", form); return "formatter-form"; } @PostMapping("/formatter/edit") public String formatterEdit(@ModelAttribute Form form) { return "formatter-view"; } @Data static class Form { @NumberFormat(pattern = "###,###") private Integer number; @DateTimeFormat(pattern = "yyyy-MM-dd HH:mm:ss") private LocalDateTime localDateTime; } } Reference 스프링 MVC 2편 - 백엔드 웹 개발 활용 기술

Java-Ecosystem · 2024-07-27

스프링 예외 처리

Java-Ecosystem · 2024-07-20

스프링 쿠키, 세션 로그인 기본

Java-Ecosystem · 2024-07-10

스프링 Validation

Validation HTTP 요청이 정상인지 검증하는 것은 컨트롤러의 중요한 역할 스프링 제공 방법 Bean Validation (Bean Validation 2.0 (JSR-380)) + BindingResult 검증 로직을 공통화 및 표준화해 객체에 애노테이션으로 검증 적용 객체에 검증 애노테이션 적용 (e.g. @NotNull, @Range…) 파라미터에 @Valid, @Validated 적용하면 검증 실행 기술 표준으로서 검증 애노테이션 및 여러 인터페이스의 모음 구현체는 일반적으로 하이버네이트 Validator를 사용 (ORM과 관련 없음) 스프링 MVC가 Bean Validator를 사용하는 과정 spring-boot-starter-validation를 라이브러리로 등록 스프링 부트가 자동으로 Bean Validator를 인지하고 스프링에 통합 스프링 부트는 LocalValidatorFactoryBean을 글로벌 Validator로 등록 애노테이션을 보고 검증을 수행하는 검증기 (e.g. @NotNull) @Valid, @Validated 적용으로 파라미터 검증 실행 검증 오류 발생 시 FieldError, ObjectError 생성해 BindingResult 담음 검증 순서 타입에 맞춰 각각의 필드 바인딩 시도 실패시 typeMismatch로 FieldError 추가 바인딩에 성공한 필드만 Bean Validation 적용 비즈니스 로직 적용 방법 컨트롤러 용도에 따라 검증 전용 객체 분리하기 (도메인 객체는 순수하게 유지) 장점: 검증 중복이 없고 복잡도 낮음 단점: 컨트롤러에서 전송 받은 데이터를 도메인 객체 생성 및 변환 과정 추가 검증 전용 객체 이름은 일관성만 있게자유로이 명명 ItemSave, ItemSaveForm , ItemSaveRequest ,ItemSaveDto… 동일한 도메인 객체 사용 + Bean Validation의 groups 속성으로 분류 - 권장 X 장점: 중간에 도메인 객체 생성 과정 없이 컨트롤러부터 리포지토리까지 전달 가능 단점: 간단한 경우에만 가능 검증할 기능을 등록 및 수정 등 각각의 그룹으로 나누어 적용 가능 저장용 groups 생성 package hello.itemservice.domain.item; public interface SaveCheck { } 수정용 groups 생성 package hello.itemservice.domain.item; public interface UpdateCheck { } groups 적용 @Data public class Item { @NotNull(groups = UpdateCheck.class) //수정시에만 적용 private Long id; @NotBlank(groups = {SaveCheck.class, UpdateCheck.class}) private String itemName; @NotNull(groups = {SaveCheck.class, UpdateCheck.class}) @Range(min = 1000, max = 1000000, groups = {SaveCheck.class, UpdateCheck.class}) private Integer price; @NotNull(groups = {SaveCheck.class, UpdateCheck.class}) @Max(value = 9999, groups = SaveCheck.class) //등록시에만 적용 private Integer quantity; public Item() { } public Item(String itemName, Integer price, Integer quantity) { this.itemName = itemName; this.price = price; this.quantity = quantity; } } @Validated에 groups 적용 (@Valid는 groups 기능이 없음) @Validated(SaveCheck.class) @Validated(UpdateCheck.class) ObjectError 처리 방법 글로벌 오류는 자바 코드로 직접 작성해 처리 권장 (메서드 추출) public String addItem(@Validated @ModelAttribute Item item, BindingResult bindingResult, RedirectAttributes redirectAttributes) { //특정 필드 예외가 아닌 전체 예외 if (item.getPrice() != null && item.getQuantity() != null) { int resultPrice = item.getPrice() * item.getQuantity(); if (resultPrice < 10000) { bindingResult.reject("totalPriceMin", new Object[]{10000, resultPrice}, null); } } ... } @ScriptAssert() - 권장 X @ScriptAssert(lang = "javascript", script = "_this.price * _this.quantity >= 10000") public class Item { //... } 생성되는 메시지 코드 ScriptAssert.item ScriptAssert 제약이 많고 복잡하여 권장하지 않음 API 적용 시 고려할 점 (HTTP 메시지 컨버터) @Valid, @Validated -> HttpMessageConverter(@RequestBody)에 적용 가능 public Object addItem(@RequestBody @Validated ItemSaveForm form, BindingResult bindingResult) API는 3가지 경우 고려 필요 성공 요청 실패 요청 HttpMessageConverter 에서 요청 JSON을 객체로 생성하는데 실패 컨트롤러 자체가 호출되지 않고 예외가 발생 검증 적용(Validator) X 검증 오류 요청 JSON 객체 생성은 성공했으나 이후 검증 실패 HttpMessageConverter 는 성공하지만 검증(Validator)에서 오류가 발생 필요한 의존관계 패키지 implementation 'org.springframework.boot:spring-boot-starter-validation jakarta.validation-api: Bean Validation 인터페이스 hibernate-validator: 구현체 검증 애노테이션 @NotBlank: null 과 "" 과 " " 모두 허용하지 않음 @NotEmpty: null 과 ""을 허용하지 않음 @NotNull: null을 허용하지 않음 @Range(min = 1000, max = 1000000): 범위 안의 값만 허용 @Max(9999): 최대 지정 값까지만 허용 테스트에서 Bean Validation 사용하기 ValidatorFactory factory = Validation.buildDefaultValidatorFactory(); Validator validator = factory.getValidator(); Set<ConstraintViolation<Item>> violations = validator.validate(item); Bean Validation 오류 코드 Bean Validation이 오류 메시지를 찾는 순서 MessageResolver 생성 메시지 코드대로 messageSource 찾기 (errors.properties) 애노테이션의 message 속성 사용 @NotBlank(message = "공백! {0}") 라이브러리가 제공하는 기본 값 사용 기본은 애노테이션 이름으로 오류코드를 등록 e.g. @NotBlank NotBlank.item.itemName NotBlank.itemName NotBlank.java.lang.String NotBlank 생성이 예상되는 적절한 오류 코드로 errors.properties에 원하는 메시지 등록 가능 BindingResult 스프링이 제공하는 검증 오류를 보관하는 객체 (Model에 자동 포함) 실제로는 인터페이스이고 Errors 인터페이스를 상속받고 있음 실제 넘어오는 구현체는 BeanPropertyBindingResult 타입으로 Errors를 사용해도 되지만 BindingResult는 더 추가적인 기능 제공 관례상으로도 Errors보다 BindingResult 많이 사용 반드시 @ModelAttribute 파라미터의 바로 뒤에 위치해야 함 e.g. @ModelAttribute Item item, BindingResult bindingResult 타임리프가 통합 기능도 제공 (#fields, th:errors, th:errorclass) 검증 오류 적용 방법 스프링 자동 적용 @ModelAttribute에 데이터 바인딩 오류가 발생 시 자동 처리 e.g. 주로 타입 오류 BindingResult가 없으면 컨트롤러 호출 X, 400 오류 페이지 이동 BindingResult가 있으면 스프링이 new FieldError() 실행 생성한 필드 에러 객체를 BindingResult에 자동으로 담음 이후 컨트롤러 정상 호출 개발자가 직접 넣기 rejectValue(), reject()를 호출하는 방법 target(검증 대상 모델)을 BindingResult가 이미 앎 (깔끔한 코드) 내부에서 MessageCodesResolver를 사용 FieldError, ObjectError 생성 후 오류 코드들을 보관 즉, MessageCodesResolver가 생성한 오류들을 가지고 처리 필드 에러 처리 (rejectValue()) bindingResult.rejectValue("quantity", "max", new Object[]{9999}, null); rejectValue() 파라미터 field: 오류 필드명 errorCode messageCodesResolver를 위한 오류 코드 필드명, 오브젝트명, 오류코드를 조합한 키로 메시지 가져옴 errorArgs: 메시지에서 사용하는 인자 defaultMessage: 오류 메시지 찾을 수 없을 때 기본 메시지 글로벌 에러 처리 (reject()) bindingResult.reject("totalPriceMin", new Object[]{10000, resultPrice}, null); reject() 파라미터 errorCode errorArgs defaultMessage 참고 ValidationUtils: Empty, 공백 등의 조건까지 한 줄로 처리 가능 ValidationUtils.rejectIfEmptyOrWhitespace(bindingResult, "itemName", "required"); FieldError, ObjectError 직접 생성을 통한 방법 (addError()) 필드 에러 처리 (FieldError) FieldError 객체를 생성해 bindingResult에 담음 FieldError는 ObjectError의 자식 bindingResult.addError(new FieldError("item", "itemName", "상품 이름은 필수입니다.")); FieldError 파라미터 (생성자 2개) objectName: @ModelAttribute 이름 field: 오류가 발생한 필드 이름 rejectedValue: 사용자가 입력한 값 (거절된 값) bindingFailure: 바인딩 실패인지, 검증 실패인지 구분 값 codes: 메시지 코드 지정 (errors.properties) 배열로 여러 값을 전달 가능 순서대로 매칭해 처음 매칭되는 메시지 사용 (없으면 예외 발생) e.g. new String[] {"max.item.quantity"} arguments: 메시지에서 사용하는 인자 {0}, {1}… 순서대로 치환 값 전달 e.g. new Object[] {9999} defaultMessage: 오류 기본 메시지 글로벌 에러 처리 (ObjectError - 특정 필드를 넘어서는 오류) ObjectError 객체를 생성해 bindingResult에 담음 bindingResult.addError(new ObjectError("item", "가격 * 수량의 합은 10,000원 이상이어야 합니다. 현재 값 = " + resultPrice)); ObjectError 파라미터 (생성자 2개) objectName: @ModelAttribute 이름 codes: 메시지 코드 arguments: 메시지에서 사용하는 인자 defaultMessage: 오류 기본 메시지 Validator 사용하기 스프링이 제공하는 Validator 인터페이스를 상속해 검증 로직을 담기 가능 컨트롤러에서 검증 로직을 분리하고 재사용할 수 있음 구현할 메서드 supports 해당 검증기 지원 여부 확인 @Override public boolean supports(Class<?> clazz) { return Item.class.isAssignableFrom(clazz); } validate(Object target, Errors errors) 검증 대상 객체와 BindingResult 전달 적용 방법 WebDataBinder 에 검증기 추가 + @Validated 파라미터 적용 @InitBinder public void init(WebDataBinder dataBinder) { log.info("init binder {}", dataBinder); dataBinder.addValidators(itemValidator); } WebDataBinder (컨트롤러에 추가) 스프링 파라미터 바인딩 역할 및 검증 기능 수행 해당 컨트롤러가 호출될 때마다 검증기 적용 즉, 요청이 올 때마다 새로 생성해 검증 글로벌 설정도 가능하지만 사용할 일 거의 없음 (권장 X) @SpringBootApplication public class ItemServiceApplication implements WebMvcConfigurer { public static void main(String[] args) { SpringApplication.run(ItemServiceApplication.class, args); } @Override public Validator getValidator() { return new ItemValidator(); } } 글로벌 설정 시 BeanValidator가 자동 등록되지 않음 @Validated 검증 실행을 원하는 파라미터에 적용 supports를 통해 등록된 검증기들 중 실행해야 할 것을 구분 검증기 직접 호출도 가능하지만 불편 개발자 직접 처리 중복 처리가 많아짐 타입 오류 처리가 안됨 Integer 타입 파라미터에 문자가 들어오면 오류 스프링 MVC에서 컨트롤러 호출되기 전부터 400 예외 발생 특히, 타입 오류의 경우 검증 전 고객의 입력 데이터를 보존하지 못함 (UX에 중요한 부분) 클라이언트 검증 & 서버 검증 클라이언트 검증만 사용하면 조작이 가능해 보안에 취약하고, 서버 검증만 있다면 즉각적인 고객 사용성이 부족해진다. 따라서, 클라이언트 검증과 서버 검증은 둘 다 적절히 섞어 사용하되, 최종적으로 서버 검증을 필수로 진행한다. @Validated와 @Valid 검증 시 @Validated, @Valid 둘 다 사용 가능하다. @Validated 는 스프링 전용 검증 애노테이션이고, @Valid 는 자바 표준 검증 애노테이션이다. 다만, @Valid는 다음 의존관계 추가가 필요하다. `implementation ‘org.springframework.boot:spring-boot-starter-validation’ javax.validation VS org.hibernate.validator javax.validation으로 시작하면 표준 인터페이스, org.hibernate.validator로 시작하면 하이버네이트 validator 구현체를 사용할 때만 제공되는 검증이다. 다만, 실무에서 대부분 하이버네이트 validator를 사용하므로 자유롭게 사용해도 된다. BeanValidation - @ModelAttribute VS @RequestBody @ModelAttribute 는 필드 단위로 정교하게 바인딩이 적용된다. 특정 필드가 바인딩 되지 않아도(타입이 맞지 않는 오류) 나머지 필드는 정상 바인딩 되고, Validator를 사용한 검증도 적용할 수 있다. @RequestBody 는 객체 단위로 바인딩이 적용된다. HttpMessageConverter 단계에서 JSON 데이터를 객체로 변경하지 못하면 이후 단계 자체가 진행되지 않고 예외가 발생한다. 컨트롤러도 호출되지 않고, Validator도 적용할 수 없다. MessageCodesResolver 검증 오류 코드로 메시지 코드 후보들을 생성 MessageCodesResolver는 인터페이스이고 DefaultMessageCodesResolver가 기본 구현체 보통 이렇게 생성된 메시지 코드를 기반으로 MessageSource에서 메시지를 찾음 기본 메시지 코드 생성 규칙 객체 오류 규칙 code + “.” + object name code e.g. 오류 코드: required, object name: item required.item required 필드 오류 규칙 code + “.” + object name + “.” + field code + “.” + field code + “.” + field type code 예) 오류 코드: typeMismatch, object name: "user", field: "age", field type: int typeMismatch.user.age typeMismatch.age typeMismatch.int typeMismatch 메시지 처리 전략 예시 (errors.properties) #==ObjectError== #Level1 totalPriceMin.item=상품의 가격 * 수량의 합은 {0}원 이상이어야 합니다. 현재 값 = {1} #Level2 totalPriceMin=전체 가격은 {0}원 이상이어야 합니다. 현재 값 = {1} #==FieldError== #Level1 required.item.itemName=상품 이름은 필수입니다. range.item.price=가격은 {0} ~ {1} 까지 허용합니다. max.item.quantity=수량은 최대 {0} 까지 허용합니다. #Level2 - 생략 #Level3 required.java.lang.String = 필수 문자입니다. required.java.lang.Integer = 필수 숫자입니다. min.java.lang.String = {0} 이상의 문자를 입력해주세요. min.java.lang.Integer = {0} 이상의 숫자를 입력해주세요. range.java.lang.String = {0} ~ {1} 까지의 문자를 입력해주세요. range.java.lang.Integer = {0} ~ {1} 까지의 숫자를 입력해주세요. max.java.lang.String = {0} 까지의 문자를 허용합니다. max.java.lang.Integer = {0} 까지의 숫자를 허용합니다. #Level4 required = 필수 값 입니다. min= {0} 이상이어야 합니다. range= {0} ~ {1} 범위를 허용합니다. max= {0} 까지 허용합니다. 메시지 처리 기본 범용 메시지를 두고, 세밀하게 작성해야 하는 경우에 세밀한 메시지를 적용하도록 메시지 단계를 두자 세밀한 메시지가 범용 메시지보다 우선순위 가진다. 예를 들어, required라는 메시지만 있으면 해당 메시지를 기본으로 사용하고, required.item.itemName 같이 세밀한 메시지 코드가 있으면 이 메시지를 높은 우선순위로 사용한다. MessageCodesResolver는 메시지 관련 공통 전략을 편리하게 적용할 수 있게 지원한다. 스프링 타입 오류 스프링은 타입 오류가 발생하면 typeMismatch라는 오류 코드를 자동으로 사용한다. 이 경우 MessageCodesResolver를 통해 4가지 메시지 코드가 발생할텐데, errors.properties에 해당 코드가 없다면 스프링이 생성한 기본 메시지가 출력된다. Failed to convert property value of type java.lang.String to required type java.lang.Integer for property price; nested exception is java.lang.NumberFormatException: For input string: "A" 기본 출력을 임의로 바꾸고 싶다면, errors.properties에 다음과 같은 코드를 적절하게 추가하면 된다. typeMismatch.java.lang.Integer=숫자를 입력해주세요. typeMismatch=타입 오류입니다. Reference 스프링 MVC 2편 - 백엔드 웹 개발 활용 기술 @NotNull, @NotEmpty, @NotBlank 의 차이점 및 사용법

Java-Ecosystem · 2024-06-30

스프링 MVC 메시지와 국제화

메시지 다양한 메시지를 한 곳에서 관리하도록 하는 기능 스프링 부트는 messages.properties를 기본 메시지 파일로 인식하고 관리 경로: /resources/messages.properties 국제화 메시지 파일을 각 나라 언어별로 별도 관리해 서비스를 국제화 베이스파일명_언어 형식으로 메시지 파일을 만들어두면 자동으로 인식 e.g. messages_en.properties, messages_ok.properties 기본은 HTTP accept-language 헤더 값을 보고 판단 스프링 부트 기본 LocaleResolver: AcceptHeaderLocaleResolver 혹은 사용자가 직접 언어를 선택하도록 하고, 쿠키나 세션 기반 처리도 가능 LocaleResolver 인터페이스의 구현체 변경 public interface LocaleResolver { Locale resolveLocale(HttpServletRequest request); void setLocale(HttpServletRequest request, @Nullable HttpServletResponse response, @Nullable Locale locale); } 찾을 수 있는 국제화 파일이 없는 경우, 언어정보 없는 디폴트 파일 기본 사용 (messages.properties) MessageSource 인터페이스 public interface MessageSource { String getMessage(String code, @Nullable Object[] args, @Nullable String defaultMessage, Locale locale); String getMessage(String code, @Nullable Object[] args, Locale locale) throws NoSuchMessageException; 스프링은 메시지 관리 기능을 MessageSource 인터페이스를 통해 제공 getMessage: 파라미터만 다르고 메시지를 읽어오는 기능 수행 메시지가 없는 경우 NoSuchMessageException 발생 code: 메시지 파일에서 지정한 키 args: 매개변수를 전달하는 배열 메시지 파일의 {0} 부분 치환 hello.name=안녕 {0} Object[] 배열로 넘겨야 함 ms.getMessage("hello.name", new Object[]{"Spring"}, null); defaultMessage: 메시지가 없을 때 기본 메시지 지정 (예외 발생 예방) locale: 국제화 파일 선택 e.g. Locale.KOREA, Locale.ENGLISH 정보가 없을 시 (null) Locale.getDefault() 호출해, 시스템 기본 로케일 사용 시스템 기본 로케일 조회 실패 시 기본 이름 메시지 파일 조회 (message.properties) Locale이 en_US인 경우 messages_en_US / messages_en / messages 순서로 찾음 스프링 부트는 자동으로 ResourceBundleMessageSource 구현체를 스프링 빈으로 등록 메시지 파일 임의 지정 방법 (application.properties) e.g. spring.messages.basename=messages,config.i18n.messages 기본값: spring.messages.basename=messages 직접 등록 방법 @Bean public MessageSource messageSource() { ResourceBundleMessageSource messageSource = new ResourceBundleMessageSource(); messageSource.setBasenames("messages", "errors"); messageSource.setDefaultEncoding("utf-8"); return messageSource; basenames: 설정 파일 이름 지정 여러 파일을 한 번에 지정 가능 (messages, errors) messages.properties, errors.properties 파일을 읽음 defaultEncoding: 인코딩 정보 지정 (utf-8 사용하면 됨) Reference 스프링 MVC 2편 - 백엔드 웹 개발 활용 기술

Java-Ecosystem · 2024-06-21

스프링 데이터 접근 활용 기술

Java-Ecosystem · 2024-06-16

JPQL Dive

JPQL 개요 단순한 조회 방법 EntityManager.find() 객체 그래프 탐색 - a.getB(), b.getC() 검색조건이 포함된 SQL의 필요성 단순 조회는 문제 없지만 애플리케이션이 필요한 데이터만 DB에서 불러오려면 결국 검색 SQL이 필요 (모든 DB 데이터를 객체로 변환해 검색하는 것은 불가능) JPQL 엔터티 객체를 대상으로 검색하는 객체 지향 SQL (JPA 제공) 반면에, SQL은 데이터베이스 테이블을 대상으로 쿼리 SQL을 추상화해서 특정 DB SQL에 의존 X JPQL은 현재 설정 Dialect와 합쳐져 현재 DB에 맞는 적절한 SQL을 생성하고 전달 DB를 바꿔서 Dialect가 바뀌었더라도 JPQL 자체를 바꿀 필요는 없음 JPQL 빌더 - QueryDSL 권장 문자가 아닌 자바코드로 JPQL을 작성할 수 있음 Criteria JPA 공식 기능 너무 복잡하고 실용성이 없음 QueryDSL 컴파일 시점에 문법 오류를 찾을 수 있음 편리한 동적쿼리 작성 단순하고 쉬움 네이티브 쿼리 - 네이티브 쿼리가 필요할 때는 JdbcTemplate을 사용하는게 낫다 JPQL로 해결할 수 없는 특정 DB 의존적인 기능 해결 e.g. 오라클 CONNECT BY, … 네이티브 SQL JPA에서 SQL을 직접 사용하는 기능 em.createNativeQuery(sql, 클래스) JDBC, JdbcTemplate, MyBatis 사용 주의점: 영속성 컨텍스트를 적절한 시점에 강제로 플러시 필요 JPA로 Persist만 해둔 데이터는 JdbcTemplate으로 커넥션을 얻어 SQL 조회시 조회 X 조회 직전 flush() 호출 필요 기본 조회 select m from Member as m where m.age > 18 테이블 이름이 아닌 엔터티 이름 사용 (Member) 별칭은 필수 (m, as는 생략 가능) 엔터티와 속성은 대소문자 구분 O JPQL 키워드는 대소문자 구분 X em.createQuery 반환 타입 TypedQuery 반환 타입이 명확할 때 사용 보통 엔터티 클래스를 넘김 TypedQuery<Member> query = em.createQuery("SELECT m FROM Member m", Member.class); Query 반환 타입이 명확하지 않을 때 사용 Query query = em.createQuery("SELECT m.username, m.age from Member m"); 결과 조회 API query.getResultList() 결과가 하나 이상일 때, 리스트 반환 결과가 없으면 빈 리스트 반환 query.getSingleResult() 결과가 정확히 하나, 단일 객체 반환 이외의 결과는 예외 일으킴 결과가 없으면 javax.persistence.NoResultException 둘 이상이면 javax.persistence.NonUniqueResultException 파라미터 바인딩 이름 기준 SELECT m FROM Member m where m.username=:username query.setParameter("username", usernameParam); 위치 기준 - 버그나기 쉬우므로 사용하지 말 것! SELECT m FROM Member m where m.username=?1 query.setParameter(1, usernameParam); 프로젝션 SELECT 절에 조회할 대상을 지정하는 것 DISTINCT로 중복 제거 엔터티 프로젝션 SELECT m FROM Member m 조회된 엔터티는 영속성 컨텍스트가 관리 SELECT m.team FROM Member m 이 경우 조인 쿼리가 나가는데 예측이 어려우므로 이 형태로 사용하지 말 것 조인쿼리는 직접 조인 쿼리로 작성하자 임베디드 타입 프로젝션 SELECT m.address FROM Member m 스칼라 타입 프로젝션 SELECT m.username, m.age FROM Member m 위와 같이 여러 값을 조회할 시 3가지 방법 존재 Query 타입으로 조회 TypedQuery에서 Object[] 타입으로 조회 DTO로 바로 조회 SELECT new jpabook.jpql.UserDTO(m.username, m.age) FROM Member m TypedQuery에서 UserDTO 타입으로 조회 패키지 명을 포함한 전체 클래스 명 입력 (문자 SQL이라 적어줘야 함) 순서와 타입이 일치하는 생성자 필요 페이징 API 각각의 DB Dialect에 맞게 JPA가 추상화 setFirstResult(int startPosition): 조회 시작 위치 (0부터 시작) setMaxResults(int maxResult): 조회할 데이터 수 //페이징 쿼리 String jpql = "select m from Member m order by m.name desc"; List<Member> resultList = em.createQuery(jpql, Member.class) .setFirstResult(10) .setMaxResults(20) .getResultList(); 조인 내부 조인 SELECT m FROM Member m [INNER] JOIN m.team t 외부 조인 SELECT m FROM Member m LEFT [OUTER] JOIN m.team t 세타 조인 연관 관계가 없는 테이블끼리 조인 (카테시안 곱 발생) select count(m) from Member m, Team t where m.username = t.name ON 절 (JPA 2.1부터 지원) 조인 대상 필터링 JPQL SELECT m, t FROM Member m LEFT JOIN m.team t on t.name = 'A' SQL SELECT m.*, t.* FROM Member m LEFT JOIN Team t ON m.TEAM_ID=t.id and t.name='A' 연관관계 없는 엔터티 외부 조인 JPQL SELECT m, t FROM Member m LEFT JOIN Team t on m.username = t.name SQL SELECT m.*, t.* FROM Member m LEFT JOIN Team t ON m.username = t.name 서브 쿼리 JPA는 WHERE, HAVING 절에서만 서브 쿼리 사용 가능 하이버네이트는 SELECT, FROM 절에서 서브 쿼리 가능하도록 지원 (FROM은 6부터 지원) 서브 쿼리 지원 함수 EXISTS (subquery): 서브쿼리에 결과가 존재하면 참 ALL (subquery): 모두 만족하면 참 ANY, SOME (subquery): 하나라도 만족하면 참 IN (subquery): 하나라도 같은 것이 있으면 참 JPQL 타입 표현 문자: ‘HELLO’, ‘She’’s’ 숫자: 10L(Long), 10D(Double), 10F(Float) Boolean: TRUE, FALSE ENUM: jpabook.MemberType.Admin (패키지명 포함) 파라미터 바인딩으로 풀면 패키지명 안 쓸 수 있음 엔티티 타입: TYPE(m) = Member (상속 관계에서 사용) em.createQuery(“select i from Item i where type(i) = Book”, Item.class) where 절에 DTYPE = ‘Book’ 으로 쿼리가 나감 조건식 CASE 식 기본 CASE 식 select case when m.age <= 10 then '학생요금' when m.age >= 60 then '경로요금' else '일반요금' end from Member m 단순 CASE 식 select case t.name when '팀A' then '인센티브110%' when '팀B' then '인센티브120%' else '인센티브105%' end from Team t COALESCE 조건식을 하나씩 차례로 조회해서 null이 아닌 조건식 반환 select coalesce(m.username,'이름 없는 회원') from Member m NULLIF 두 값이 같으면 null 반환, 다르면 첫 번째 값 반환 select NULLIF(m.username, '관리자') from Member m JPQL 기본 함수 및 사용자 정의 함수 JPQL 기본 함수 CONCAT SUBSTRING TRIM LOWER, UPPER LENGTH LOCATE: 문자 위치 찾기 (locate('de', 'abcdegf')) ABS, SQRT, MOD SIZE (JPA 용도): 컬렉션의 크기를 리턴 (select size(t.members) from Team t) 사용자 정의 함수 호출 등록 방법 Hibernate 6는 FunctionContributer 구현체를 만들어야 함 Hibernate 6 이전에는 방언을 상속받고 사용자 정의 함수 등록했음 src/main/resources/META-INF/services/org.hibernate.boot.model.FunctionContributor 위 파일을 생성해 구현체 등록 (custom.CustomFunctionContributor) package custom; import org.hibernate.boot.model.FunctionContributions; import org.hibernate.boot.model.FunctionContributor; import org.hibernate.dialect.function.StandardSQLFunction; import org.hibernate.type.StandardBasicTypes; public class CustomFunctionContributor implements FunctionContributor { @Override public void contributeFunctions(FunctionContributions functionContributions) { functionContributions.getFunctionRegistry() .register("group_concat", new StandardSQLFunction("group_concat", StandardBasicTypes.STRING)); } } 호출 방법 select function('group_concat', i.name) from Item i 경로표현식 .을 찍어 객체 그래프를 탐색하는 것 경로표현식에 의한 묵시적 조인은 쓰지 말자 최대한 JPQL과 실제 SQL의 모양을 맞춰 예측가능하게 만들어야 함 조인은 쿼리 튜닝에 중요 포인트이기 때문 유의사항: 묵시적 조인은 항상 내부 조인 명시적 조인 사용하자! (별칭으로 상세 탐색 가능) select m.username from Team t join t.members m 용어 상태 필드 (state field) 단순히 값을 저장하기 위한 필드 경로 탐색의 끝 (탐색 X) m.username 연관 필드 (association field) 연관 관계를 위한 필드 단일 값 연관 필드 대상이 엔터티 (@ManyToOne, @OneToOne) 묵시적 내부 조인 발생 (탐색 O) select m.team from Member m (e.g.m.team) 컬렉션 값 연관 필드 대상이 컬렉션 (@OneToMany, @ManyToMany) 묵시적 내부 조인 발생 (탐색 X) select t.members from Team t (e.g. t.members) 페치 조인 (fetch join) - join fetch JPQL에서 성능 최적화를 위해 연관된 엔터티나 컬렉션을 SQL 한 번에 함께 조회하는 기능 페치 조인으로 가져온 연관 엔터티는 프록시가 아닌 실제 엔터티 지정한 엔터티를 즉시 로딩으로 가져오므로, N + 1 문제를 해결 사용 전략 글로벌 로딩 전략은 모두 지연로딩으로 가져가고 최적화가 필요한 곳에 페치 조인 적용 조인 사용 전략 페치 조인으로 가져오기 (객체 그래프를 유지할 때 사용하면 효과적) 페치 조인으로 가져오고 애플리케이션 단에서 알맞는 DTO로 전환해 사용 일반 조인으로 필요한 데이터들만 조회해 DTO로 프로젝션 반환 여러 테이블을 조인해 원래의 엔터티 모양과 전혀 다른 결과를 내야 한다면 일반조인 사용 페치 조인과 일반 조인과의 차이 페치 조인은 회원을 조회하면 연관된 팀도 함께 조회 (SELECT T.*, M.*) [JPQL] select t from Team t join fetch t.members [SQL] SELECT T.*, M.* FROM TEAM T INNER JOIN MEMBER M ON T.ID=M.TEAM_ID 일반 조인은 연관된 엔터티를 함께 조회 X (SELECT T.*) [JPQL] select t from Team t join t.members m [SQL] SELECT T.* FROM TEAM T INNER JOIN MEMBER M ON T.ID=M.TEAM_ID 컬렉션 페치 조인 일대다 관계에서 실행하는 페치 조인 하이버네이트 6 이후 JPQL DISTINCT 없이도 애플리케이션에서 자동으로 중복 제거 적용 하이버네이트 6 이전 조인 시 데이터 중복 발생 DB와 객체의 차이 때문에 같은 엔터티 중복 발생 실제 팀은 1개인데 멤버와의 조인으로 발생한 행 수에 의해 2개의 팀이 반환 teamname = 팀A, team = Team@0x100 -> username = 회원1, member = Member@0x200 -> username = 회원2, member = Member@0x300 teamname = 팀A, team = Team@0x100 -> username = 회원1, member = Member@0x200 -> username = 회원2, member = Member@0x300 JPQL DISTINCT 컬렉션 페치 조인 데이터 중복 방지를 위해 적용 JPQL DISTINCT는 2가지 기능을 제공 SQL에 DISTINCT 추가 실제 SQL에 적용되지만, SQL 결과에서는 중복 제거할 것이 없음 애플리케이션에서 엔터티 중복 제거 애플리케이션 단에서 같은 식별자를 가진 엔터티 제거 DISTINCT 적용시 결과 teamname = 팀A, team = Team@0x100 -> username = 회원1, member = Member@0x200 -> username = 회원2, member = Member@0x300 유의 사항 여러 엔터티 다중 페치 조인 시에만 대상에 별칭을 쓰자 하이버네이트에서는 페치 조인 대상에 별칭 사용 가능 (가급적 사용 X) 페치 조인은 연관된 엔터티를 몇 개 걸러서 가져와서는 안됨 (정합성 이슈) 페치 조인은 연관된 엔터티를 항상 모두 가져와야 함 e.g. 팀 조회 시, 팀에 연관된 멤버가 5명일 때 멤버 3명만 가져와서는 안됨 이는 누락을 동반하는 매우 위험한 조작 (Cascade etc…) JPA 설계 사상은 연관된 모든 것을 다 조회하는 것을 전제하므로 위반 조심 둘 이상의 컬렉션은 페치 조인하지 말자 페치 조인은 컬렉션을 딱 하나만 지정하자 예상치 못하게 데이터 중복이 늘어날 수 있음 e.g Team.members, Team.orders를 한꺼번에 페치 조인해서는 안됨 컬렉션을 페치 조인하면 페이징 API 사용 불가 (메모리 페이징 문제로 매우 위험) 페이징 API: setFIrstResult, setMaxResults 문제 데이터 중복 1:M 컬렉션 페치 조인은 단순히 DB 상 조인 쿼리를 생성 DB에서 조인된 테이블의 로우는 M개 (1 기준으로는 중복된 row가 많은 상황) 따라서, 생성된 DB 쿼리 상 1 기준 페이징이 불가능 데이터 누락 문제가 JPA의 객체 그래프 사상을 위반 e.g. 팀 A에 멤버가 2명 있을 때, 이를 페치 조인해 pageSize를 1로 페이징 페이징은 철저히 DB 중심 -> 팀 & 멤버 조인 테이블에서 1개 row를 가져옴 (멤버1) DB 결과에 따라 JPA는 팀 A에 멤버가 1명 있다고 생각해 문제 발생 (멤버2 누락) 데이터 중복 및 누락을 피하기 위해 메모리 페이징 발생 (장애 유발 가능성 높음) 하이버네이트는 경고 로그를 남기고 강제로 메모리에서 페이징 (매우 위험) 실제로 조인 쿼리만 날리고 DB에서 페이징하지 않고 메모리에서 페이징 e.g. 100만 건 데이터를 모두 메모리에 올리고 메모리에서 페이징… 해결 방법 일대다 쿼리를 다대일 쿼리로 바꿔 실행 (권장) 일대일, 다대일 같은 단일 값 연관 필드들은 페치 조인해도 당연히 페이징 가능 쿼리 한 번으로 해결되므로 일반적으로 성능이 좋음 팀과 멤버 (OneToMany)에서 멤버 테이블로 페이징 쿼리 후 팀 기준 group by batchSize 적용 페치 조인을 하지 않고 지연 로딩 활용 (팀에 페이징 쿼리하고 멤버를지연로딩) 배치 사이즈는 N + 1 쿼리를 막고 설정한 단위 기준으로 in-query 진행 기본적으로 글로벌 배치 사이즈 깔고 모든 작업 진행 1000 이하의 적절한 수 지정 (보통 DB의 in 절 개수의 한계가 1000) persistence.xml <property name="hibernate.default_batch_fetch_size" value="100" /> application.properties spring: jpa: properties: hibernate: default_batch_fetch_size: 100 e.g. 팀이 150개고 멤버가 레이지 로딩될 때, batchSize가 100개인 상황 원래는 150개의 N + 1 쿼리가 발생하지만 이를 예방 100개 & 50개 뭉치로 총 2번 in-query해 가져옴 DTO 쿼리 다형성 쿼리 상속 관계 매핑에서 사용 type 조회 대상을 특정 자식으로 한정 (=DTYPE where 절 자동 적용) e.g. Item 중 Book, Movie 조회하기 [JPQL] select i from Item i where type(i) IN (Book, Movie) [SQL] select i from i where i.DTYPE in (‘B’, ‘M’) treat (JPA 2.1) 부모 타입을 특정 자식 타입으로 다룸 타입 캐스팅과 유사 FROM, WHERE, SELECT(하이버네이트) 절에서 사용 가능 e.g. 부모인 Item과 자식 Book이 있을 때, 자식 속성으로 where절 걸고 싶은 경우 [JPQL] select i from Item i where treat(i as Book).author = ‘kim’ [SQL] select i.* from Item i where i.DTYPE = ‘B’ and i.author = ‘kim’ 엔터티 직접 사용 JPQL에서 엔터티를 직접 사용하면 SQL에서 해당 엔터티의 기본키 값 사용 [JPQL] select count(m.id) from Member m - 엔티티의 아이디를 사용 select count(m) from Member m - 엔티티를 직접 사용 [SQL] select count(m.id) as cnt from Member m - JPQL 둘 다 같은 SQL 실행 연관된 엔터티를 직접 사용하면 외래키 값 사용 [JPQL] select m from Member m where m.team = :team select m from Member m where m.team.id = :teamId [SQL] select m.* from Member m where m.team_id=? - JPQL 둘 다 같은 SQL 실행 Named 쿼리 미리 정의해서 이름을 부여해두고 사용하는 JPQL (=정적 쿼리) 에노테이션, XML에 정의 XML 정의가 항상 우선권을 가짐 애플리케이션 운영 환경에 따라 다른 XML 배포 가능 애플리케이션 로딩 시점에 초기화 후 재사용 - JPQL을 SQL로 미리 파싱 후 캐싱 약간의 속도 이점 애플리케이션 로딩 시점에 미리 쿼리의 예외를 검증하는 이점 에노테이션 정의 사용 예 @Entity @NamedQuery( name = "Member.findByUsername", query="select m from Member m where m.username = :username") public class Member { ... } List<Member> resultList = em.createNamedQuery("Member.findByUsername", Member.class) .setParameter("username", "회원1") .getResultList(); XML 정의 사용 예 [META-INF/persistence.xml] <persistence-unit name="jpabook" > <mapping-file>META-INF/ormMember.xml</mapping-file> [META-INF/ormMember.xml] <?xml version="1.0" encoding="UTF-8"?> <entity-mappings xmlns="http://xmlns.jcp.org/xml/ns/persistence/orm" version="2.1"> ... <named-query name="Member.findByUsername"> <query><![CDATA[ select m from Member m where m.username = :username ]]></query> </named-query> <named-query name="Member.count"> <query>select count(m) from Member m</query> </named-query> </entity-mappings> 벌크 연산 여러 개의 데이터에 대한 갱신 쿼리 벌크연산은 주로 JPQL로 진행 JPA 자체는 실시간 단건성 작업에 적합 JPA 변경 감지 기능으로 실행하려면 너무 많은 SQL 실행 e.g. 100건의 엔터티라면 100번의 UPDATE SQL 실행 executeUpdate() 영향 받은 엔터티 수 반환 쿼리 한 번으로 여러 테이블 로우 변경 UPDATE, DELETE 지원 String qlString = "update Product p " + "set p.price = p.price * 1.1 " + "where p.stockAmount < :stockAmount"; int resultCount = em.createQuery(qlString) .setParameter("stockAmount", 10) .executeUpdate(); insert into .. select 하이버네이트가 INSERT 지원 벌크 연산 사용 전략 JPQL은 영속성 컨텍스트를 무시하고 DB에 직접 쿼리하므로 벌크 연산 사용 맥락이 중요 사용 전략 1: 벌크 연산을 먼저 실행 영속성 컨텍스트에 아무 것도 하지 않고 벌크 연산만 실행 영속성 컨텍스트가 비어 있으니 벌크 연산으로 새로 조회가 발생해도 문제 없음 DB에서 최신 데이터 가져와 1차캐시에 반영할 것이므로 사용 전략 2: 벌크 연산 수행 후 영속성 컨텍스트 초기화 (em.clear()) 어떤 엔터티가 미리 조회되어 있는 상황에서 벌크 연산을 진행 JPQL 호출로 플러시 자동 발생 벌크 연산 후 영속성 컨텍스트는 DB에 비해 Old한 상태가 됨 e.g. 처음 조회한 회원 엔터티의 연봉이 5000만원 이후 수행한 벌크 연산에서 연봉이 6000만원이 되어 DB에 플러시됨 이 경우 애플리케이션에서는 여전히 회원 연봉이 5000만원임 따라서, 영속성 컨텍스트를 비워주어 깨끗한 상태에서 다시 조회될 수 있도록 해야 함 Reference 자바 ORM 표준 JPA 프로그래밍 - 기본편

Java-Ecosystem · 2024-06-08

JPA Dive

Java-Ecosystem · 2024-06-02

스프링 데이터 접근 핵심 원리

Java-Ecosystem · 2024-05-12

스프링 MVC 원리

Web Server & Web Application Server Web Server (HTTP) 정적 리소스 제공 + 기타 부가기능 동적인 처리(애플리케이션 로직 등)가 필요하면 WAS에 요청 위임 예시) NGINX, APACHE Web Application Server (HTTP) 애플리케이션 로직 수행 (프로그램 코드 실행) + 웹 서버 기능 (정적 리소스 제공) 동적 HTML, HTTP API(JSON), 서블릿, JSP, Spring MVC API 서버만 제공할 경우 WAS만으로 서버 구축해도 괜찮음 (회사끼리 데이터 주고 받을 때) 예시) Tomcat, Jetty, Undertow WAS는 애플리케이션 코드 실행에 더 특화되어 있다! 웹서버와 WAS는 서로가 서로의 기능을 가지고 있긴 해서 경계가 모호 서블릿 컨테이너 기능 제공하면 WAS라 보기도 함 (서블릿 사용안하는 프레임워크도 있지만…) 공존 이유 효율적인 리소스 관리 WAS가 너무 많은 역할을 담당하여 서버 과부하 우려 애플리케이션 로직은 값어치가 높으므로 값이 낮은 정적 리소스 때문에 과부하되면 안됨 역할 분리 정적 리소스 사용이 많을 때는 Web Server 증설 애플리케이션 리소스 사용이 많을 때는 WAS 증설 지속적인 오류 화면 제공 WAS는 잘 죽는 반면, Web Server는 잘 안 죽음 WAS 및 DB 장애시 Web Server가 오류화면 제공 가능 Servlet 메시지 수신, 파싱, 응답 메시지 생성 및 송신 등 HTTP 스펙의편리한 사용을 지원하는 자바 클래스 서블릿을 지원하는 WAS를 사용하면, 의미있는 비즈니스 로직에만 집중 가능 사용 방법 메인 함수가 실행되는 클래스에 @ServletComponentScan 추가 HttpServlet을 상속받고 @WebServlet 애노테이션에 name과 urlPatterns를 지정 protected의 service 코드를 오버라이딩해 비즈니스 로직 작성 HttpServletRequest와 HttpServletResponse 타입 파라미터로 요청 및 응답 정보 사용 가능 부가 기능 임시 저장소 기능: HTTP 요청의 시작과 끝까지 유지, View에 데이터 전달하는 Model 역할도 수행 세션 관리 기능: request.getSession(create: true) 흐름 HTTP 요청시 WAS가 Request, Response 객체를 생성해서 서블릿 객체 호출 서비스 로직에서 Request 객체의 HTTP 요청 정보를 이용하고 Response 객체에 응답 정보 입력 WAS는 Response 객체에 담긴 내용으로 HTTP 응답 정보 생성 Servlet Container(서블릿 컨테이너) 서블릿을 지원하는 WAS (톰캣) 서블릿 객체의 생명주기 관리 (생성, 초기화, 호출, 종료) 서블릿 객체를 싱글톤으로 관리 최초 로딩 시점에 서블릿 객체를 미리 만들어두고 재활용 공유 변수 사용에는 주의해야 함 동시 요청을 위한 멀티 쓰레드 처리 지원 덕분에 개발자가 멀티 쓰레드를 신경쓰지 않고 마치 싱글 쓰레드 프로그래밍 하듯이 편리하게 개발 (WAS가 개발 생산성을 가장 높여주는 부분) 멀티 쓰레드 환경이므로 싱글톤 객체(서블릿, 스프링 빈)는 주의해서 사용 (공유변수, 멤버변수 조심) 동시요청 (멀티 쓰레드) 쓰레드 애플리케이션 코드를 하나하나 순차적으로 실행하는 것 (한번에 하나의 코드 라인만 수행) 자바 메인 메서드를 처음 실행하면 main이라는 이름의 쓰레드가 실행 동시 처리가 필요하면 쓰레드를 추가로 생성 서블릿 객체는 쓰레드가 호출 멀티 쓰레드는 동시요청 처리 가능 (단일 쓰레드로는 처리가 어려움) 요청마다 쓰레드 생성 장점 동시 요청 처리 가능 하나의 쓰레드가 지연 되어도, 나머지 쓰레드는 정상 동작 단점 쓰레드 생성 비용은 매우 비쌈 (요청마다 쓰레드 생성하면 응답 속도도 늦어짐) 컨텍스트 스위칭 비용 발생 (하나의 CPU 코어에 2개 이상의 쓰레드를 돌리면 발생) 쓰레드 생성에 제한 없음 (요청이 너무 많으면, CPU와 메모리 임계점을 넘어 서버가 죽음) 쓰레드 풀 설정한 최대치 만큼 쓰레드를 미리 생성해 풀에 보관하고 관리 (톰캣 기본설정: 최대 200개) 요청이 들어오면 쓰레드 풀에서 쓰레드를 할당하고 다 쓰면 반납 (재사용) 풀에 남은 쓰레드가 부족하면 대기 중인 요청은 거절하거나 특정 숫자만큼만 대기하도록 설정 가능 장점 쓰레드를 미리 생성하므로, 쓰레드 생성 비용(CPU)이 절약되고 응답이 빠름 쓰레드 풀 최대치가 있으므로 너무 많은 요청이 들어와도 기존 요청은 안전하게 처리 가능 WAS의 주요 튜닝 포인트는 최대 쓰레드 수(max thread) 동시 요청이 많은 상황에서 너무 낮게 설정 시: 서버 리소스는 여유롭지만, 금방 클라이언트 응답 지연이 발생 100개 요청이 왔는데 최대 쓰레드가 10개면 동시에 10개 요청만 처리 그런데 사실 CPU는 5% 밖에 사용안함 너무 높게 설정 시: CPU, 메모리 임계점 초과로 서버 다운 발생 10000개의 요청이 오면 10000개를 모두 받아들이다가 서버가 죽음 장애 발생시 클라우드면 일단 서버부터 늘리고 이후 튜닝 클라우드가 아니면 바로 튜닝 적정 쓰레드 풀 숫자는 성능 테스트를 통해 찾아야 함 애플리케이션 로직 복잡도, CPU & 메모리 & IO 리소스 상황에 따라 모두 다름 최대한 실제 서비스와 유사하게 성능 테스트 시도 아파치 ab, 제이미터, nGrinder 백엔드가 고려할 3가지 HTTP 통신 정적 리소스 어떻게 제공할지 동적 HTML 페이지 어떻게 제공할지 (View Template) API 어떻게 제공할지 (JSON) MVC 패턴 배경 비즈니스 로직과 뷰는 변경의 라이프 사이클이 다르므로, 분리하는 것이 좋은 설계 역할을 나누면 유지보수성이 향상되고 각각의 기능을 특화할 수 있음 컨트롤러 (Controller) HTTP 요청을 받아서 파라미터를 검증하고 비즈니스 로직 및 오케스트레이션 작업 실행 오케스트레이션: 데이터 접근 및 모델 담기 등의 작업 지금은 더 고도화 되어서 다음 두 가지 패턴을 띔 서비스 계층: 비즈니스 로직 + 오케스트레이션 서비스 계층: 오케스트레이션 / 도메인 모델: 비즈니스 로직 모델 (Model) 뷰에 출력할 데이터를 담아둠 뷰 (View) 화면을 렌더링하는 일에 집중 HTML 생성에 더하여 XML, Excel, JSON 생성 등도 포괄 SSR & CSR 서버 사이드 렌더링 (SSR) HTML 최종 결과를 서버에서 만들어서 웹브라우저에 전달 JSP, Thymeleaf (백엔드 기술) 클라이언트 사이드 렌더링 (CSR) HTML 최종 결과를 JS를 이용해 웹 브라우저에서 동적으로 생성해 적용 필요한 부분만 부분부분 변경 React, Vue.js (프론트엔드 기술) CSR + SSR 동시 지원하는 프론트 기술도 존재하므로 칼같이 나눌 필요 X (Next.js) SSR도 JS 이용해 화면 일부를 동적으로 변경 가능 자바 웹기술 역사 Servlet(1997) HTML 생성이 어려움 (동적 HTML을 생성할 수 있으나 자바코드로 일일히 HTML 만들어야 해서 불편) JSP(1999) HTML 생성이 편리해 JSP로 모두 개발 비즈니스 로직과 뷰 로직이 결합되어 코드라인이 너무 많아지고 유지보수 저하 Servlet + JSP MVC 패턴 모델, 뷰, 컨트롤러로 역할을 나눠 비즈니스 로직과 화면 렌더링 부분을 나눔 한계점: 공통 기능 처리가 어려움 dispatcher.forward() 같은 View로 이동하는 코드 중복 /WEB-INF/views 와 .jsp 같은 ViewPath 중복 (JSP 의존성도 증가) HttpServletResponse response는 파라미터로 항상 존재하지만 사용 X 공통 기능을 메서드로 뽑는 방안도 여전히 호출 중복이 존재하며 호출을 강제하지는 못함 프론트 컨트롤러 패턴의 등장 배경 MVC 프레임워크 춘추 전국 시대 (2000년 초 ~ 2010년 초) 반복되는 MVC 패턴을 자동화하기 위해 여러 프레임워크 등장 스트럿츠, 웹워크, 스프링 MVC(과거 버전) 당시에는 스트럿츠 + 스프링 코어(MVC 제외한 service, DAO, repository) 형태를 주로 사용 FrontController 패턴 적용 프론트 컨트롤러 서블릿 하나로 클라이언트 요청을 받음 (나머지 컨트롤러는 서블릿 사용 X) 프론트 컨트롤러가 요청에 맞는 컨트롤러를 찾아 호출 공통 처리 담당 스프링 MVC 핵심도 프론트 컨트롤러 패턴 애노테이션 기반의 스프링 MVC MVC 프레임워크 혼돈 시대 정리 @RequestMapping 기반의 애노테이션 컨트롤러 등장으로, 스프링은 MVC 부분에서도 완승 스프링 부트 (Spring Boot) 빌드 결과(Jar)에 WAS 서버(Tomcat)를 포함하여 빌드 배포를 단순화 빌드된 Jar 파일을 아무 서버에 넣고 말아서 실행하면 됨 과거에는 서버에 WAS(Tomcat)를 직접 설치하고 Jar 파일을 모아 War 파일을 만들어서 배포를 위한 특정 폴더에 집어 넣어 배포해야 했음 최신 기술 - 스프링 웹 기술의 분화 Web Servlet - Spring MVC 서블릿 위에 Spring MVC를 올려서 동작 Web Reactive - Spring WebFlux 비동기 Non-Blocking 처리 최소 쓰레드로 최대 성능 (컨텍스트 스위칭 비용 효율화) CPU 코어가 4개 있으면 쓰레드 개수를 4 혹은 +1(5개) 정도로 맞춤 고효율로 CPU 개수에 딱 맞췄기 때문에 쓰레드가 계속 돌아가고 컨텍스트 스위칭 비용이 거의 안듦 함수형 스타일로 개발 - 동시처리 코드 효율화 WAS에서 상품 조회, 주문 서버 조회 등 여러 개의 서버에 여러 개 API를 동시에 찔러서 데이터를 가져와 조합해야 할 때 매우 효율적 Java 코드는 깔끔하지 않지만 함수형 스타일 코드는 매우 깔끔 (Netty) 서블릿 사용 X 단점 기술적 난이도 매우 높음 RDB 지원 부족 NoSQL(Redis, Elastic Search, DynamoDB, MongoDB)은 지원 잘 됨 일반 MVC 쓰레드 모델도 충분히 빠름 좋은 장비 띄워서 쓰레드 1000개 넣고 돌려도 잘 돌아감 실무에서 아직 많이 사용 X 자바 뷰 템플릿 역사 JSP 느린 속도, 부족한 기능 Freemarker, Velocity 빠른 속도 (Thymeleaf 보다 빠름) Thymeleaf (권장) 네추럴 템플릿 HTML 태그 속성을 이용하므로 HTML의 모양을 유지하면서 뷰 템플릿 적용 가능 스프링 MVC와 강한 기능 통합 스프링 MVC 핵심 구조와 원리 구조 DispatcherServlet 프론트 컨트롤러 (스프링 MVC의 핵심) 부모 클래스로부터 HttpServlet을 상속 받아, 서블릿으로서 동작 스프링 부트는 DispatcherServlet을 서블릿으로 자동 등록하면서, 모든 경로(urlPatterns="/")에 대해서 매핑 흐름 서블릿이 호출되면 DispatcherServlet의 부모인 FrameworkServlet에서 오버라이드한 HttpServlet에서 제공하는 service() 메서드가 호출됨 이후 여러 메서드가 호출되다가 DispatcherServlet.doDispatch()를 호출 HandlerMapping 요청 URL과 핸들러(컨트롤러)의 매핑 핸들러 (Handler) 컨트롤러를 포괄 꼭 컨트롤러 개념이 아니더라도 어떠한 것이든 어댑터가 지원하면 처리 가능 HandlerAdapter (in 핸들러 어댑터 목록) 다양한 버전의 규격이 다른 핸들러들을 호환 가능하게 도움 프레임워크를 유연하고 확장성 있게 설계 가능 어댑터 패턴 덕분에 프론트 컨트롤러가 다양한 방식의 컨트롤러를 처리 가능 핵심 메서드 boolean supports(Object handler) 어댑터가 해당 컨트롤러를 처리할 수 있는지 판단 ModelAndView handle(HttpServletRequest request, HttpServletResponse response, Object handler) 실제 컨트롤러를 호출하고 ModelAndView 반환 컨트롤러가 ModelAndView를 반환하지 못하면, 어댑터가 직접 생성해서라도 반환 ModelAndView 논리 뷰 이름을 가짐 뷰 렌더링에 필요한 모델 객체 포함 ViewResolver (물리 뷰 경로 반환기) 논리 뷰 이름을 실제 물리 뷰 경로로 변경 e.g. return new View("/WEB-INF/views/" + viewName + ".jsp"); View 물리 뷰 경로를 가짐 모델 정보와 함께 render() 메서드를 호출 (해당 물리명 주소로 servlet의 forward 함수 호출) 동작 순서 핸들러 조회: 핸들러 매핑을 통해 요청 URL에 매핑된 핸들러(컨트롤러)를 조회 자동 등록된 HandlerMapping들을 순서대로 실행해 핸들러 탐색 스프링 부트가 자동 등록하는 핸들러 매핑 종류 (우선순위 내림차순) RequestMappingHandlerMapping: 애노테이션 기반 컨트롤러에 사용 (@RequestMapping) BeanNameUrlHandlerMapping: 스프링 빈의 이름으로 핸들러 탐색 (@Component("...")) 핸들러 어댑터 조회: 핸들러를 실행할 수 있는 핸들러 어댑터 조회 자동 등록된 HandlerAdapter들의 supports()를 순서대로 호출 스프링 부트가 자동 등록하는 핸들러 어댑터 종류 (우선순위 내림차순) RequestMappingHandlerAdapter: 애노테이션 기반 컨트롤러에 사용 (@RequestMapping) HttpRequestHandlerAdapter: HttpRequestHandler 인터페이스 처리 (서블릿 유사) SimpleControllerHandlerAdapter: Controller 인터페이스 처리 (과거) 핸들러 어댑터 실행 핸들러 실행: 핸들러 어댑터가 실제 핸들러 실행 ModelAndView 반환: 핸들러 어댑터는 핸들러의 반환 결과를 ModelAndView로 변환해 반환 @ResponseBody, HttpEntity(ResponseEntity) 있는 경우 ViewResolver 호출하지 않고 이대로 종료 ViewResolver 호출: 뷰 리졸버를 찾고 실행 주어진 논리 뷰 이름으로 자동 등록된 viewResolver들을 순서대로 호출 스프링 부트가 자동 등록하는 뷰 리졸버 BeanNameViewResolver: 빈 이름으로 뷰를 찾아서 반환 (엑셀 파일 생성에 사용) InternalResourceViewResolver: JSP를 처리할 수 있는 뷰를 반환 application.properties 파일에 prefix와 suffix 등록 (권장) spring.mvc.view.prefix=/WEB-INF/views/ spring.mvc.view.suffix=.jsp View 반환: 뷰 리졸버는 뷰의 논리 이름을 물리 이름으로 바꾸고, 뷰 객체 반환 JSP의 경우 InternalResourceView(JstlView)를 반환 (내부에 forward() 로직 존재) 다른 뷰 템플릿들은 forward() 과정 없이 바로 렌더링 뷰 렌더링: 뷰 객체의 render() 메서드 호출 스프링 MVC 기본 기능 Controller 관련 기능 컨트롤러 애노테이션 @Controller 스프링이 자동으로 컨트롤러로 인식해 스프링 빈으로 등록 반환 값이 String이면 뷰 이름으로 인식하여, 뷰를 찾고 렌더링 @RestController 스프링이 자동으로 컨트롤러로 인식해 스프링 빈으로 등록 반환 값으로 HTTP 메시지 바디에 바로 입력 (@Controller + @ResponseBody) @RequestMapping 요청 정보 URL 매핑 대부분의 속성을 배열로 제공하므로 다중 설정 가능 {"/hello-basic", "/hello-go"} HTTP 메서드를 설정하지 않으면 메서드 모두 허용 설정하려면 아래와 같이 적용해야 해서 불편함 @RequestMapping(value = "/", method = RequestMethod.GET) HTTP 메서드 축약 애노테이션 제공 @GetMapping/@PostMapping/@PutMapping/@PatchMapping/@DeleteMapping @RequestMapping 내포 클래스 레벨 + 메서드 레벨 조합 적용 (효율적 URL 매핑 적용) @Controller @RequestMapping("/springmvc/members") public class SpringMemberController { @GetMapping("/new-form") // @RequestMapping도 가능 public ModelAndView newForm() { ... } @PostMapping("/save") // @RequestMapping도 가능 public ModelAndView save() { ... } @GetMapping // @RequestMapping도 가능 public ModelAndView members() { ... } } 경로 변수 조회 기본 사용법 @PathVariable("userId") String userId 경로변수 이름과 변수명이 같으면 생략 가능 @PathVariable String userId HTTP 헤더 조회 모든 헤더 조회 @RequestHeader MultiValueMap<String, String> headerMap 하나의 키에 여러 값을 받는 HTTP header, 쿼리 파라미터를 처리 가능 특정 헤더 조회 @RequestHeader("host") String host 속성: required (필수 값 여부), defaultValue (기본값) 특정 쿠키 조회 @CookieValue(value = "myCookie", required = false) 속성: required (필수 값 여부), defaultValue (기본값) 서블릿 조회 HttpServletRequest request HttpServletResponse response 특수 조회 Locale locale HttpMethod httpMethod … HTTP 요청 파라미터 조회 (GET 쿼리 파라미터, POST HTML Form) @RequestParam("요청 파라미터 이름") request.getParameter("파라미터 이름")와 유사 요청 파라미터와 변수명이 같으면 생략 가능 Primitive 타입이면 @RequestParam도 생략가능 required=false 자동 적용 완전 생략은 과한 측면도 있으니 유의 속성: required (필수 값 여부), defaultValue (기본값) Map으로 조회하기 @RequestParam Map<String, Object> paramMap @RequestParam MultiValueMap<String, Object> paramMap 파라미터의 값이 1개가 확실하다면 Map을 사용하지만, 아니라면 MultiValueMap을 사용 서블릿 조회 HttpServletRequest의 request.getParameter() HTTP 요청 메시지 바디 조회 @RequestBody HttpMessageConverter 사용 (요청이 content-type: application/json일 때) 헤더 정보가 필요할 땐, HttpEntity 혹은 @RequestHeader 사용할 것 생략 불가능 단순 Text (StringHttpMessageConverter) @RequestBody String messageBody JSON (MappingJackson2HttpMessageConverter) @RequestBody HelloData data 직접 만든 객체 지정 HttpEntity 조회 HttpMessageConverter 사용 (요청이 content-type: application/json일 때) 단순 Text (StringHttpMessageConverter) HttpEntity<String> httpEntity String messageBody = httpEntity.getBody(); JSON (MappingJackson2HttpMessageConverter) HttpEntity<HelloData> httpEntity RequestEntity HttpEntity를 상속 받음 HttpMethod, URL 정보 추가 가능 서블릿 조회 단순 Text HttpServletRequest request ServletInputStream inputStream = request.getInputStream(); String messageBody = StreamUtils.copyToString(inputStream, StandardCharsets.UTF_8); InputStream inputStream String messageBody = StreamUtils.copyToString(inputStream, StandardCharsets.UTF_8); JSON 단순 Text와 유사하나 다음 코드가 추가됨 private ObjectMapper objectMapper = new ObjectMapper(); Jackson 라이브러리 ObjectMapper를 사용 (JSON to 자바 객체) MappingJackson2HttpMessageConverter가 하는 작업을 수동으로 진행 HelloData data = objectMapper.readValue(messageBody, HelloData.class); 조건 매핑 파라미터 특정 파라미터 조건 매핑 (params) @GetMapping(value = "/mapping-param", params = "mode=debug") 특정 요청 파라미터 포함한 요청만 받음 http://localhost:8080/mapping-param?mode=debug 특정 헤더 조건 매핑 (headers) @GetMapping(value = "/mapping-header", headers = "mode=debug") 미디어 타입 조건 매핑 HTTP 요청 헤더 Content-Type (consume) @PostMapping(value = "/mapping-consume", consumes = "application/json") 만약 맞지 않으면 상태코드 415 Unsupported Media Type 반환 사용 예시 consumes = "text/plain" consumes = {"text/plain", "application/*"} consumes = MediaType.TEXT_PLAIN_VALUE HTTP 요청 헤더 Accept (produce) @PostMapping(value = "/mapping-produce", produces = "text/html") 만약 맞지 않으면 상태코드 406 Not Acceptable 반환 사용예시 produces = "text/plain" produces = {"text/plain", "application/*"} produces = MediaType.TEXT_PLAIN_VALUE produces = "text/plain;charset=UTF-8" required & defaultValue 속성 required 속성 required의 기본값은 true 주의사항 파라미터 이름만 사용하는 요청의 경우 @RequestParam(required = true) String username 요청: /request-param-required?username= -> 빈 문자열로 통과 요청: /request-param-required -> 400 예외 발생 Primitive 타입에 null 입력하는 경우 @RequestParam(required = false) int age 요청: /request-param -> 500 예외 발생 (null을 int에 입력 불가능) 해결 방법 @RequestParam(required = false) Integer age 요청: /request-param -> null 입력 통과 @RequestParam(required = false, defaultValue = "-1") int age 요청: /request-param -> 기본값이 있으므로 required가 무의미 defaultValue 속성 파라미터에 값이 없는 경우 지정한 기본값 적용 기본 값이 있기 때문에 required는 의미 없어짐 빈 문자의 경우도 기본값 적용 (요청: /request-param-default?username=) 클라이언트 to 서버 데이터 전달 방법 3가지 쿼리 파라미터 (GET) HTML Form (POST, 메시지 바디에 쿼리 파라미터 형식으로 전달) HTTP message body (POST, PUT, PATCH) 요청 파라미터 VS HTTP 메시지 바디 요청 파라미터 조회: @RequestParam, @ModelAttribute (생략 가능) HTTP 메시지 바디 조회: @RequestBody (생략 불가능, 생략하면 @ModelAttribute로 기능) 스프링 부트 3.2: 파라미터 이름 생략시 발생하는 예외 (@PathVariable, @RequestParam) java.lang.IllegalArgumentException: Name for argument of type [java.lang.String] not specified, and parameter name information not found in class file either. 해결방법 1. 파라미터 이름을 생략하지 않고 항상 적기 해결방법 2. 컴파일 시점에 -parameters 옵션 추가 (File -> Settings -> Build, Execution, Deployment → Compiler → Java Compiler -> Additional command line parameters) 해결방법 3. Gradle을 사용해서 빌드하고 실행 (권장) View 관련 기능 정적 리소스 (HTML, CSS, JS 제공) 스프링 부트는 기본 정적 리소스 경로 제공 src/main/resources/static 실제 서비스에서도 공개되기 때문에 공개할 필요없는 HTML을 두는 것을 조심할 것! 접근 요청: http://localhost:8080/basic/hello-form.html 제공: src/main/resources/static/basic/hello-form.html 뷰 템플릿 (동적 HTML 제공) 스프링 부트는 기본 뷰 템플릿 경로 제공 src/main/resources/templates 사용 방법 String 반환 ViewName 직접 반환 (뷰의 논리 이름을 리턴) @ResponseBody가 없으면 뷰 리졸버를 실행 String 반환: 리다이렉트 지원 (RedirectView) redirect:/ return "redirect:/basic/items/{itemId}"; RedirectAttributes 함께 사용 권장 URL에 ID 값을 넣을 때 URL 인코딩이 안되어 위험 URL 인코딩 + 경로변수, 쿼리 파라미터 처리 @PostMapping("/add") public String addItem(Item item, RedirectAttributes redirectAttributes) { Item savedItem = itemRepository.save(item); redirectAttributes.addAttribute("itemId", savedItem.getId()); redirectAttributes.addAttribute("status", true); return "redirect:/basic/items/{itemId}"; } ModelAndView 생성 및 반환 (권장 X) ModelAndView mv = new ModelAndView("뷰 논리경로") mv.addObject("객체 이름", 실제 객체): 모델에 데이터 추가 void 반환 (권장 X) 요청 URL을 참고해 논리 뷰 이름으로 사용 /response/hello(요청) -> templates/response/hello.html (실행) 실행 조건 @Controller O HTTP 메시지 바디 처리 파라미터 X (HttpServletResponse, OutputStream) 접근 반환: response/hello 실행: templates/response/hello.html HTTP 응답 메시지 바디 직접 입력 (API 방식, 정적 리소스나 뷰 템플릿 거치치 않음) @ResponseBody HttpMessageConverter 사용 단순 Text (StringHttpMessageConverter) -> String 리턴 JSON (MappingJackson2HttpMessageConverter) -> Java 객체 리턴 상태코드 입력: @ResponseStatus @ResponseStatus(HttpStatus.OK) 클레스 레벨 및 메서드 레벨 모두 적용 가능 HttpEntity HttpMessageConverter 사용 단순 Text (StringHttpMessageConverter) -> String 리턴 JSON (MappingJackson2HttpMessageConverter) -> Java 객체 리턴 return new HttpEntity<>("ok"); ResponseEntity HttpEntity를 상속 받음 HTTP Status Code 추가 가능 단순 Text 반환 타입 선언: ResponseEntity<String> return new ResponseEntity<>("Hello World", responseHeaders, HttpStatus.CREATED) JSON 반환 타입 선언: ResponseEntity<HelloData> return new ResponseEntity<>(helloData, HttpStatus.OK) 서블릿 응답 HttpServletResponse response response.getWriter().write("ok"); Writer responseWriter responseWriter.write("ok"); Model 관련 기능 @Controller @RequestMapping("/springmvc/v3/members") public class SpringMemberControllerV3 { private MemberRepository memberRepository = MemberRepository.getInstance(); @GetMapping("/new-form") public String newForm() { return "new-form"; } @PostMapping("/save") public String save( @RequestParam("username") String username, @RequestParam("age") int age, Model model) { Member member = new Member(username, age); memberRepository.save(member); model.addAttribute("member", member); return "save-result"; } @GetMapping public String members(Model model) { List<Member> members = memberRepository.findAll(); model.addAttribute("members", members); return "members"; } } Model model 파라미터 선언으로 편리하게 모델 사용 가능 model.addAttribute("객체 이름", 실제 객체): 모델에 데이터 추가 @ModelAttribute 요청 파라미터를 받아 객체에 바인딩하는 과정을 자동화 Primitive 이외 타입은 @ModelAttribute 생략가능 (argument resolver 지정타입 외) 이름을 생략하면 클래스 명의 첫글자만 소문자로 바꿔서 모델에 등록 (HelloData -> helloData) @ModelAttribute HelloData helloData 실행 과정 HelloData 객체 생성 요청 파라미터 이름으로 HelloData 객체의 프로퍼티 찾고 setter를 호출해 바인딩 @Data public class HelloData { private String username; private int age; } // 롬복 @Data = @Getter + @Setter + @ToString + // @EqualsAndHashCode + @RequiredArgsConstructor // 위험하기 때문에 사용 주의! DTO는 괜찮지만 핵심 도메인 모델엔 사용 X @ModelAttribute - 컨트롤러 레벨 적용 @ModelAttribute("regions") public Map<String, String> regions() { Map<String, String> regions = new LinkedHashMap<>(); regions.put("SEOUL", "서울"); regions.put("BUSAN", "부산"); regions.put("JEJU", "제주"); return regions; } 컨트롤러 클래스 내에 별도의 메서드로서 @ModelAttribute를 적용 가능 해당 클래스 내 모든 컨트롤러는 호출 시 미리 정의한 모델이 자동으로 담김 (반복 데이터 처리에 유리) HTTP 메시지 컨버터 @ResponseBody 사용시 반환값을 HTTP Body에 직접 입력 viewResolver 대신 HttpMessaveConverter 동작 HTTP Accept 헤더와 컨트롤러의 반환 타입 정보를 조합해 적절한 HttpMessageConverter 선택 HttpMessageConverter 인터페이스로서 HTTP 요청 및 응답에 모두 사용 주요 메서드 canRead(), canWrite(): 메시지 컨버터가 해당 클래스, 미디어타입을 지원하는지 체크 read(), write(): 메시지 컨버터를 통해 메시지를 읽고 쓰는 기능 동작 클래스 타입을 먼저 바라보고 컨버터 종류 채택 후, 미디어 타입 지원 확인 HTTP 요청 데이터 읽기 요청이 오고 컨트롤러는 @RequestBody, HttpEntity(RequestEntity) 사용 canRead() 호출 (메시지 컨버터가 메시지 읽을 수 있는 지 확인) 대상 클래스 타입을 지원하는가 (@RequestBody의 대상 클래스) HTTP 요청의 Content-Type 헤더의 미디어 타입을 지원하는가 조건을 만족하면 read() 호출해, 객체 생성 및 반환 HTTP 응답 데이터 생성 컨트롤러에서 @ResponseBody, HttpEntity(ResponseEntity)로 값을 반환 canWrite() 호출 (메시지 컨버터가 메시지를 쓸 수 있는지 확인) 대상 클래스 타입을 지원하는가 (return의 대상 클래스) 미디어 타입을 지원하는가 @RequestMapping의 produces가 세팅되어 있으면 이 값을 기준으로 처리 아니라면 HTTP 요청의 Accept 헤더의 미디어 타입을 지원하는지 여부 확인 조건을 만족하면 write() 호출해, HTTP 응답 메시지 바디에 데이터 생성 스프링 부트 기본 메시지 컨버터 (우선순위 순서로) ByteArrayHttpMessageConverter 기본이 바이트 배열로 오므로 변환 없이 그대로 받이들이는 것 클래스 타입: byte[], 미디어 타입: */* 요청 예 @RequestBody byte[] data 응답 예 @ResponseBody return byte[] 쓰기 미디어 타입: application/octet-stream StringHttpMessageConverter 바이트로 오는 데이터를 문자열로 처리 클래스 타입: String, 미디어타입: */* 요청 예 @RequestBody String data 응답 예 @ResponseBody return "ok" 쓰기 미디어타입: text/plain MappingJackson2HttpMessageConverter 바이트로 오는 데이터를 객체 또는 HashMap으로 처리 클래스 타입: 객체 또는 HashMap, 미디어 타입: application/json 요청 예 @RequestBody HelloData data 응답 예 @ResponseBody return helloData 쓰기 미디어타입: application/json HTTP 메시지 컨버터의 위치 HTTP 메시지 컨버터는 RequestMappingHandlerAdapter에서 실제로 사용 (애노테이션 기반) RequestMappingHandlerAdapter 동작 방식 ArgumentResolver 호출 정확히는 HandlerMethodArgumentResolver 핸들러의 파라미터, 애노테이션 정보를 기반으로 핸들러가 필요로 하는 요청 데이터 생성 (HttpServletRequest, Model, @RequestParam, @ModelAttribute, @RequestBody, HttpEntity) 과정 ArgumentResolver 구현체들을 탐색하며 (InvocableHandlerMethod) supportsParameter() 호출 (해당 파라미터 지원 여부 체크) 지원 가능하면 resolveArgument() 호출 (실제 객체 생성) HTTP 메시지 컨버터 사용해 데이터 처리 후 리턴 (canRead(), read()) 핸들러 호출 (with 생성된 요청 데이터) ReturnValueHandler 정확히는 HandlerMethodReturnValueHandler 컨트롤러의 반환 값을 변환해 응답 데이터 생성 (ModelAndView, @ResponseBody, HttpEntity) 과정 ReturnValueHandler 구현체들을 탐색하며 (ServletInvocableHandlerMethod) supportsReturnType() 호출 (해당 리턴 타입 지원 여부 체크) 지원 가능하면 handleReturnValue() 호출 HTTP 메시지 컨버터 사용해 데이터 처리 (canWrite(), write()) HTTP 메시지 컨버터 적용 경우 스프링 MVC는 다음 상황에서 HTTP 메시지 컨버터를 적용한다. HTTP 요청: @RequestBody, HttpEntity(RequestEntity) HTTP 응답: @ResponseBody, HttpEntity(ResponseEntity) 스프링 MVC 주요 ArgumentResolver & ReturnValueHandler @RequestBody, @ResponseBody 존재: RequestResponseBodyMethodProcessor() 사용 HttpEntity 존재: HttpEntityMethodProcessor() 사용 기능 확장 기능 확장은 WebMvcConfigurer 상속 및 스프링 빈 등록을 통해 구현한다. 스프링은 다음을 모두 인터페이스로 제공하므로, 언제든 커스터마이징 기능 확장이 가능하다. HandlerMethodArgumentResolver HandlerMethodReturnValueHandler HttpMessageConverter @Bean public WebMvcConfigurer webMvcConfigurer() { return new WebMvcConfigurer() { @Override public void addArgumentResolvers(List<HandlerMethodArgumentResolver> resolvers) { //... } @Override public void extendMessageConverters(List<HttpMessageConverter<?>> converters) { //... } }; } Reference 스프링 MVC 1편 - 백엔드 웹 개발 핵심 기술 View, ViewResolver (SERVLET) @RequestBody는 어떻게 동작할까?

Java-Ecosystem · 2024-04-21

스프링 로깅 기본

로깅 (Logging) 스프링 부트 로깅 라이브러리(spring-boot-starter-logging)에서 다음 로깅 라이브러리 사용 SLF4J 라이브러리: 로그 라이브러리를 통합해서 인터페이스로 제공 (Logback, Log4J, Log4J2…) Logback 라이브러리: 실무에서 구현체 로그 라이브러리로 주로 사용 (스프링 부트 기본 제공) 로그 선언 기본 사용법 private static final Logger log = LoggerFactory.getLogger(getClass()); 롬복 사용 @Slf4j 다음 코드를 자동 생성 private static final Logger log = LoggerFactory.getLogger(Xxx.class); 올바른 로그 사용법 올바른 사용법: log.debug("data={}", data) 잘못된 사용법: log.debug("String concat log=" + name) 로그 출력 레벨을 info로 설정하면 로그 남지 않으나, 더하기 연산은 무조건 수행되어 비효율 로그 출력 포멧 시간 / 로그 레벨 / 프로세스 ID / 쓰레드 명 / 클래스명 / 로그 메시지 로그 레벨 수준 (정보가 많은 순서로) TRACE > DEBUG > INFO > WARN > ERROR DEBUG: 개발 서버 적합 INFO: 운영 서버 적합 로그 레벨별 호출 방법 //@Slf4j @RestController public class LogTestController { private final Logger log = LoggerFactory.getLogger(getClass()); @RequestMapping("/log-test") public String logTest() { String name = "Spring"; log.trace("trace log={}", name); log.debug("debug log={}", name); log.info(" info log={}", name); log.warn(" warn log={}", name); log.error("error log={}", name); return "ok"; } } 로그 레벨 전역 설정 (application.properties) 전체 로그 레벨 설정 (디폴트: info) logging.level.root=info 특정 패키지 및 하위 패키지 로그 레벨 설정 logging.level.hello.springmvc=debug 장점 쓰레드 정보, 클래스 이름 같은 부가 정보 확인 가능 출력 포멧 조절 가능 로그 레벨 설정으로 상황에 맞게 조절 가능 파일, 네트워크 등 콘솔 뿐만 아니라 별도의 위치에 남길 수 있음 (파일의 경우 일별, 용량별 분할 가능) System.out 보다 성능도 좋음 Reference 스프링 MVC 1편 - 백엔드 웹 개발 핵심 기술

Java-Ecosystem · 2024-04-14

JPA 활용 팁 1

JPA 테이블 설계 Tips 주문 테이블은 orders로 주로 사용 (예약어 order by 때문에) 테이블 이름은 소문자 + _ 스타일 사용 실무에서 @ManyToMany는 사용하지 말자 중간 테이블에 컬럼을 추가할 수 없고 세밀한 쿼리가 어려움 @ManyToOne, @OneToMany로 풀어내서 사용 연관 관계에서 외래 키가 있는 곳을 연관 관계의 주인으로 정하기 (One-to-Many에서는 Many가 주인) Getter, Setter는 모두 제공하지 않고, 꼭 필요한 별도 메서드만 제공하는게 가장 이상적이지만 실무는 다름 Getter는 모두 열어놓으면 실무상 편리 엔티티 변경은 Setter를 모두 열어두기 보다 비즈니스 메서드를 별도 제공해 변경 지점이 명확하도록 함 엔티티의 식별자는 id로 쓰더라도 PK 컬럼명은 테이블명_id로 사용하자 Foreign key와 이름을 맞출 수 있는 장점 DBA들도 선호 Cascade=ALL 엔티티를 persist하면 다른 연관관계 엔티티까지 persist를 전파 Delete할 때는 모두 같이 지워짐 값 타입(임베디드 타입)은 변경 불가능하게 설계 @Setter를 제거하고 생성자에서 초기화 강제 기본 생성자를 protected로 두어 안전 향상 JPA 스펙 상 엔티티 및 임베디드 타입은 기본 생성자를 public 혹은 protected로 두어야 함 JPA가 객체 생성시 리플랙션 같은 기술을 사용할 수 있도록 지원해야 하기 때문 실무에서는 검증 로직이 있어도 멀티 쓰레드 상황을 고려해 변경 컬럼에 유니크 제약 조건 추가하는 것이 안전 엔티티 설계 시 주의점 모든 연관관계는 지연로딩(Lazy)으로 설정 즉시로딩(Eager)은 예측이 어렵고 N + 1 문제가 자주 발생 연관 관계 엔티티 로딩 시 fetch join 혹은 엔티티 그래프 기능 사용 @XToOne 관계는 기본이 즉시로딩이므로 직접 지연로딩 설정을 해야 함 컬렉션은 필드에서 초기화 null 문제에서 안전 Hibernate은 엔티티 영속화 시 컬렉션을 감싸서 Hibernate이 제공하는 내장 컬렉션으로 변경 (PersistentBag) - 필드 초기화가 내부 매커니즘을 안전하게 지켜줌 테이블, 컬럼명 생성 전략 기본 전략 하이버네이트 기존 구현 엔티티의 필드명을 그대로 테이블 컬럼명으로 사용 SpringPhysicalNamingStrategy 스프링 부트 신규 설정 Camel case -> Snake case . -> _ 추가 전략 명시적으로 컬럼, 테이블명을 적으면 실제 테이블에 물리명 적용 (physical-strategy) 적지 않은 경우 논리명 적용 (implicit-strategy) 애노테이션 Tips @PersistenceContext 엔티티 매니저(EntityManger) 주입 Lombok 생성자 주입 사용시 애노테이션 생략 가능 @Transactional readOnly=true 플러시를 하지 않으므로 약간의 성능 향상 디폴트는 readOnly=false이므로, 큰 스코프에서 readOnly=true를 설정하고 커맨드성 작업에 @Transactional을 붙이는 방식으로 사용하면 편리 테스트에 붙으면, 테스트 종료 후 자동으로 트랜잭션 롤백 테스트를 환경을 위한 설정 파일 테스트 케이스에는 메모리 DB 사용이 효율적 데이터 소스나 JPA 관련 별도 추가 설정을 하지 않아도 됨 스프링 부트는 datasource 설정이 없으면 기본적으로 메모리 DB 사용 스프링 부트는 jpa 설정이 없으면 ddl-auto: create-drop 모드로 동작 설정 파일 읽기 전략 테스트에서 스프링을 실행하면, test/resources/application.yml을 읽음 해당 위치에 없을 경우, src/resources/application.yml 읽음 도메인 모델 패턴 VS 트랜잭션 스크립트 패턴 도메인 모델 패턴 엔티티가 비즈니스 로직을 가지고 객체 지향의 특성을 적극 활용하는 패턴 (서비스 계층은 단순히 엔티티에 필요한 요청을 위임하는 역할) 트랜잭션 스크립트 패턴 엔티티에는 비즈니스 로직이 거의 없고 서비스 계층에서 대부분의 비즈니스 로직을 처리하는 패턴 변경 감지(Dirty Checking) & 병합(merge) 준영속 엔티티 영속성 컨텍스트가 더이상 관리하지 않는 엔티티 이전에 DB에 한 번 저장되어서 식별자가 존재하나 JPA가 현재 추적하고 있지 않는 객체 준영속 엔티티를 수정하는 2가지 방법 변경 감지(Dirty Checking) - Recommendation 동작 식별자로 엔티티를 조회(find)한 후 데이터 수정 컨텍스트가 종료되면서 트랜잭션 커밋 시점에 변경 감지가 동작하고, 데이터베이스에 UPDATE SQL 실행 병합(merge) 동작 준영속 엔티티의 식별자 값으로 영속 엔티티를 조회 영속 엔티티의 값을 준영속 엔티티의 값으로 모두 교체 (병합) 트랜잭션 커밋 시점에 변경 감지 기능이 동작해서 데이터 베이스에 UPDATE SQL 실행 병합은 모든 필드를 변경해버리고 데이터가 없으면 null로 업데이트하므로 위험 Best Practice: 엔티티 변경시 항상 변경 감지 사용하기 컨트롤러에서 엔티티 생성하지 말기 서비스 계층에 식별자(id)와 변경할 데이터를 명확히 전달 (파라미터 or DTO) 서비스 계층에서 영속 상태의 엔티티를 조회하고, 엔티티의 데이터를 직접 변경 트랜잭션 커밋 시점에 변경 감지 자동 실행

Java-Ecosystem · 2024-03-26

스프링 부트 프로젝트 세팅

스프링 프로젝트 세팅 방법 프로젝트 GENERATE: https://start.spring.io Spring Boot Version은 SNAPSHOT, M2가 들어가지 않은 것이 정식 버전 Package name은 -가 안들어가도록 주의 ADD DEPENDENCIES: Spring WEB, Thymeleaf, Lombok, Validation, JPA, H2… Settings Lombok Plugins - Lombok 설치 Annotation Processing - Enable annotation processing Gradle - Build and run using, Run tests using - IntelliJ IDEA 변경 Main 함수 실행 - White label page 확인 H2 Database 세팅 방법 설치 - H2 Database 데이터베이스 파일 생성 (첫 진입) jdbc:h2:~/jpashop 다음 파일 생성 확인: ~/jpashop.mv.db 이후부터 TCP 연결 jdbc:h2:tcp://localhost/~/jpashop JPA 및 DB 설정 main/resources/application.yml spring: datasource: url: jdbc:h2:tcp://localhost/~/jpashop username: sa password: driver-class-name: org.h2.Driver jpa: hibernate: ddl-auto: create properties: hibernate: # show_sql: true # System.out을 통해 SQL 남김 (지양) format_sql: true logging.level: org.hibernate.SQL: debug org.hibernate.orm.jdbc.bind: trace ddl-auto create: 애플리케이션 실행 시점에 테이블을 drop하고 다시 생성 none: 테이블을 생성하지 않음 format_sql SQL이 포멧팅되어 조금 더 보기 좋게 나오게 함 org.hibernate.SQL (권장, 로그로 남기는게 좋음) logger를 통해 SQL 남김 org.hibernate.orm.jdbc.bind: trace SQL 실행 파라미터(쿼리 파라미터)를 로그로 남김 외부 라이브러리 (가독성 높은 쿼리 파라미터 로그) implementation 'com.github.gavlyukovskiy:p6spy-spring-boot-starter:1.9.0' 커넥션 정보, 가독성 높은 쿼리 파라미터 등 상세 정보 제공 시스템 자원을 잡아 먹으므로 운영 시스템에 적용하려면 반드시 성능 테스트 필요 (개발 단계 자유 사용) QueryDSL 설정 방법 (스프링 부트 3.0 이상) JDK 17 이상, 빌드 옵션으로는 Gradle 선택하기 (IntelliJ X) Preferences - Annotation Processors - Enable annotation processing 체크 build.gradle에 아래 설정 추가 //Querydsl 추가 implementation 'com.querydsl:querydsl-jpa:5.0.0:jakarta' annotationProcessor "com.querydsl:querydsl-apt:${dependencyManagement.importedProperties['querydsl.version']}:jakarta" annotationProcessor "jakarta.annotation:jakarta.annotation-api" annotationProcessor "jakarta.persistence:jakarta.persistence-api" 예제 엔터티(@Entity) 만들기 (Hello.class) Gradle - Tasks - build: build 작업 진행 생성된 build 폴더를 삭제하고 다시 하고 싶을 때는 clean 작업 진행 build - generated - sources - annotationProcessor - … - Q파일 생성 확인 (디렉토리) Test 설정 파일 spring: logging.level: org.hibernate.SQL: debug 경로: test/resources/application.yml 유용한 명령어 의존관계 확인 (Tree view) 프로젝트 디렉토리 - ./gradlew dependencies -configuration compileClasspath 서버 재시작 없이 View 파일 변경하기 spring-boot-devtools 라이브러리 추가 html 파일만 컴파일 (build - Recompile) 초기 데이터 생성 @Slf4j @RequiredArgsConstructor public class TestDataInit { private final ItemRepository itemRepository; /** * 확인용 초기 데이터 추가 */ @EventListener(ApplicationReadyEvent.class) public void initData() { log.info("test data init"); itemRepository.save(new Item("itemA", 10000, 10)); itemRepository.save(new Item("itemB", 20000, 20)); } } @EventListener(ApplicationReadyEvent.class) 스프링 컨테이너가 완전히 초기화를 끝내고, 실행 준비가 되었을 때 발생하는 이벤트 스프링 컨테이너가 AOP를 포함해 완전히 초기화된 시점 @PostConstruct의 경우, AOP 같은 부분이 다 처리되지 않은 시점에 호출될 수 있음 예를 들어, @Transactional 관련 AOP가 적용되지 않고 호출될 수 있어 문제 스프링은 이 시점에, initData()를 호출 프로필 (Profile) 프로필은 로컬, 운영 환경, 테스트 실행 등 다양한 환경에 따라 다른 설정을 할 때 사용하는 정보 로컬에서는 로컬 DB, 운영 환경에서는 운영 DB에 접근 환경에 따라 다른 스프링 빈 등록 스프링은 로딩 시점에 spring.profiles.active 사용 (spring.profiles.active=local) main 프로필: src/main/resources 하위 application.properties test 프로필: src/test/resources 하위 **`application.properties 프로필을 지정하지 않으면 "default" 프로필로 동작 설정파일(Config) 및 프로필 적용하기 @Import(MemoryConfig.class) @SpringBootApplication(scanBasePackages = "hello.itemservice.web") public class ItemServiceApplication { public static void main(String[] args) { SpringApplication.run(ItemServiceApplication.class, args); } @Bean @Profile("local") public TestDataInit testDataInit(ItemRepository itemRepository) { return new TestDataInit(itemRepository); } } @Import(MemoryConfig.class) 원하는 설정파일 적용 @Profile("local") 특정 프로필의 경우에만 해당 스프링 빈 등록 주요한application.properties 설정 트랜잭션 프록시가 호출하는 트랜잭션의 시작 및 종료 로그 확인 가능 logging.level.org.springframework.transaction.interceptor=TRACE logging.level.org.springframework.jdbc.datasource.DataSourceTransactionManager=DEBUG JPA 커밋 롤백 로그 확인 logging.level.org.springframework.orm.jpa.JpaTransactionManager=DEBUG logging.level.org.hibernate.resource.transaction=DEBUG JPA SQL 로그 확인 logging.level.org.hibernate.SQL=DEBUG logging.level.org.hibernate.orm.jdbc.bind=TRACE HTTP 요청 메시지 확인하기 logging.level.org.apache.coyote.http11=trace

Java-Ecosystem · 2024-03-15

스프링 핵심원리 - 기본편

Java-Ecosystem · 2024-03-11

스프링 시작하기

빌드 및 실행 방법 ./gradlew build cd build/libs java -jar hello-spring-0.0.1-SNAPSHOT.jar 빌드가 잘 안될 때는 ./gradlew clean build 후 다시 빌드 (빌드 폴더 삭제) 주요 라이브러리 의존관계 스프링 부트 라이브러리 spring-boot-starter-web spring-boot-starter-tomcat: 톰캣 (웹서버) spring-webmvc: 스프링 웹 MVC spring-boot-starter-thymeleaf: 타임리프 템플릿 엔진(View) spring-boot-starter(공통): 스프링 부트 + 스프링 코어 + 로깅 spring-boot spring-core spring-boot-starter-logging logback, slf4j 테스트 라이브러리 spring-boot-starter-test junit: 테스트 프레임워크 mockito: 목 라이브러리 assertj: 테스트 코드를 좀 더 편하게 작성하게 도와주는 라이브러리 spring-test: 스프링 통합 테스트 지원 웹 개발 유형 변화 정적 컨텐츠 서버가 HTML 파일을 브라우저에게 그대로 넘겨주는 방식 과거에는 뷰와 컨트롤러 분리 없이 뷰로 모든 것을 다 하는 모델 원 방식을 사용 static/index.html 해당 경로로 index.html을 생성해두면 Welcome page가 된다. 예시 요청: localhost:8080/hello-static.html 톰켓 서버가 스프링 컨테이너에 요청 전달 요청에 대한 컨트롤러가 없다면, resources/static/hello-static.html을 찾아 브라우저에 반환 MVC와 템플릿 엔진 컨트롤러에서 리턴 값으로 문자를 반환하면 뷰 리졸버(viewResolver)가 화면을 찾아 처리한다. 템플릿 엔진 viewName 매핑 resources/templates 하위에 있는 {viewName}.html 파일을 찾아 템플릿 엔진 처리 후 브라우저에 반환 예시 요청: localhost:8080/hello-mvc 톰켓 서버가 스프링 컨테이너에 요청 전달 요청에 대한 컨트롤러를 찾음 컨트롤러는 hello-template이라는 문자열을 반환 viewResolver는 viewName 매핑으로 resources/templates/hello-template.html을 찾음 viewResolver가 Thymeleaf 템플릿 엔진에게 처리를 넘김 템플릿 엔진이 렌더링해서 변환한 HTML을 브라우저에게 반환 API @ResponseBody를 붙인 컨트롤러는 viewResolver를 사용하지 않는다. 결과 값을 JSON 형태로 HTTP Body에 담아 반환한다. viewResolver 대신 HttpMessageConverter가 동작 HTTP Accept 헤더와 컨트롤러 반환 타입 정보를 조합해 HttpMessageConverter가 선택됨 StringHttpMessageConverter (기본 문자처리) MappingJackson2HttpMessageConverter (기본 객체처리) xmlHttpMessageConverter (accept header에 xml로 요청) 예시 요청: localhost:8080/hello-api 톰켓 서버가 스프링 컨테이너에 요청 전달 요청에 대한 컨트롤러를 찾음 @ResponseBody가 붙은 컨트롤러이므로 반환값이 HttpMessageConverter에 전달됨 HttpMessageConverter가 데이터를 직렬화 후 HTTP Body에 담아 반환 Spring Bean 스프링 빈은 각 객체들 간의 의존관계를 저장하여 사용하기 편리하게 지원한다. 의존관계 등록방법 자동 의존관계 설정 (Component Scan) 정형화된 컨트롤러, 서비스, 레포지토리 같은 코드에 컴포넌트 스캔을 사용한다. 컴포넌트 등록 @Component 애노테이션이 있으면 스프링 빈으로 자동 등록된다. 다음 어노테이션들은 @Component를 포함하고 있어 역시 자동 등록된다. @Controller @Service @Repository @Autowired 해당 어노테이션이 붙은 메소드에게 스프링이 자동으로 연관 객체를 DI(의존성 주입)한다. 생성자에 사용시 객체 생성시점에 의존성 주입한다. 생성자가 하나라면 @Autowired 생략 가능 수동 의존관계 설정 (SpringConfig.java) 정형화되지 않거나 상황에 따라 구현 클래스를 변경해야 한다면 직접 설정으로 등록한다. 레포지토리를 다양하게 변경해야 하는 상황이라면 관리 포인트가 하나가 되어 편리 등록 방법 @Service, @Repository, @Autowired 등 현 상황에 불필요한 어노테이션은 제거 현재 앱 디렉토리에 SpringConfig.java 클래스 생성 클래스에 @Configuration, 메서드에 @Bean 어노테이션을 설정 메서드마다 필요한 인스턴스를 반환 @Configuration public class SpringConfig { @Bean public MemberService memberService() { return new MemberService(memberRepository()); } @Bean public MemberRepository memberRepository() { return new MemoryMemberRepository(); } } 특징 스프링은 스프링 빈에 등록할 때, 객체를 싱글톤으로 등록한다. 즉, 같은 스프링 빈이면 모두 같은 인스턴스여서 메모리가 절약된다. (설정으로 변경은 가능) 예시 주문 컨트롤러에서 멤버 서비스, 멤버 레포지토리를 요청하면 똑같은 인스턴스를 넣어 줌 스프링 통합 테스트 테스트 클래스에 다음 어노테이션을 추가한다. @SpringBootTest 스프링 컨테이너와 테스트를 함께 실행한다. @Transactional 테스트 케이스에 해당 어노테이션을 추가하면, 테스트 시작 전에 트랜잭션을 시작하고 테스트 완료 후 항상 롤백한다. 덕분에 DB에 데이터가 남지 않아 각각의 테스트가 서로 영향을 주지 않는다. 스프링 DB 접근 기술 순수 JDBC 관련 코드들이 매우 장황하고 반복이 많다. JdbcTemplate SQL은 여전히 직접 작성하지만, JDBC의 반복 코드를 대부분 제거해준다. JPA ORM의 개념으로 넘어왔다. 데이터 중심 설계에서 객체 중심 설계 패러다임으로 전환할 수 있고 생산성을 크게 높인다. jdbc 관련 라이브러리가 포함되어 있다. 항상 @Transactional을 사용해서 데이터 변경을 트랜잭션 안에서 실행 시켜야 한다. 스프링 데이터 JPA 인터페이스만으로 개발 가능 메서드 이름만으로 조회 기능 제공 페이징 기능 자동 제공 단순 반복 코드가 크게 줄어드는 덕분에 개발자는 비즈니스 로직에 집중할 수 있다. Querydsl 복잡한 동적 쿼리 작업 AOP Aspect of Programming 관점 지향 프로그래밍 어떤 로직을 핵심 관심 사항, 공통 관심 사항으로 나누고 그 관점을 바탕으로 각각 모듈화 핵심 관심 사항 (core concern) 비즈니스 로직 공통 관심 사항 (cross-cutting concern) DB 연결, 로깅, 파일 입출력, API 계층별 응답 시간 측정 etc… @Aspect, @Around AOP in Spring 스프링은 프록시 방식의 AOP를 사용 스프링은 AOP가 있으면 서버가 올라올 때 컨테이너에서 스프링 빈에 등록하면서 가짜 스프링 빈을 앞에 세우고 그것이 끝나면 진짜 스프링 빈을 호출하도록 동작한다. (가짜 서비스 후 진짜 서비스 호출) 컨트롤러에서 서비스를 호출하면 서비스 코드는 스프링 빈을 통해 가짜 프록시 서비스를 의존성 주입 받고 해당 프록시 서비스가 끝나면 다시 실제 서비스 코드가 의존성 주입을 받아 실행된다. 이 방식은 스프링이 DI가 가능하기 떄문에 할 수 있는 기술 Reference 스프링 입문 - 코드로 배우는 스프링 부트, 웹 MVC, DB 접근 기술

Java-Ecosystem · 2024-02-08

자바 객체 지향 설계

클래스가 필요한 이유 String[] studentNames = {"학생1", "학생3", "학생4", "학생5"}; int[] studentAges = {15, 17, 10, 16}; int[] studentGrades = {90, 100, 80, 50}; 학생이라는 개념을 다룰 때, 배열과 반복문으로 데이터를 처리해야 하므로 데이터 변경 시 실수할 가능성이 높다. 따라서 사람이 관리하기 좋은 코드를 만들기 위해 학생이라는 개념을 하나의 클래스로 묶어야 한다. 클래스 특징 클래스를 통해 마음껏 사용자 정의 타입을 만들 수 있다. (설계도) 클래스에 정의한 변수들 = 멤버 변수(Member variable) = 필드(Field) 실제 메모리에 만들어진 실체를 객체 혹은 인스턴스라 한다. 클래스 타입 변수는 객체를 생성하면 해당 객체의 참조값을 담는다. System.out.println(student); // 출력값 // (패키지 + 클래스 정보 @ 16진수 참조값) class1.Student@7a81197d 클래스 & 인스턴스 & 객체 클래스 객체 생성을 위한 ‘틀’ 또는 ‘설계도’ 객체가 가져야 할 속성(변수)과 기능(메서드)를 정의한다. 인스턴스 클래스로부터 생성된 객체 인스턴스 = 객체 어떤 클래스에 속해 있는지 강조 (관계에 초점) 객체 클래스의 속성과 기능을 가진 실체 세상 모든 사물을 단순하게 추상화해보면 속성과 기능 2가지만 남는다. 변수의 값 초기화 멤버 변수: 자동 초기화 인스턴스 생성시 자동 초기화 (new로 만드는 객체들의 멤버 변수들은 모두 자동 초기화된다.) int = 0, boolean = fasle, 참조형 = null 직접 초기화 지정 가능 지역 변수: 수동 초기화 null 참조형 변수에서 아직 가리키는 대상이 없다면 null을 넣어둘 수 있다. Data data = null; 아무도 참조하지 않는 인스턴스 (feat. GC) 참조형 변수에 null을 할당하면 해당 참조 데이터가 메모리에 남아 있다가 GC(Garbage Collector)에 의해 제거된다. 메소드가 종료되어 지역변수가 사라질 때, 지역변수가 참조하고 있던 인스턴스 역시 메모리에 남아 있다가 GC에 의해 제거된다. NullPointerException null에 .을 찍을 때 발생하는 에러이므로 디버깅시 유의하자. this 인스턴스 자신의 참조값을 가리킨다. 생성자에서 지역변수 이름이 겹친다면 this를 통해 멤버변수에 접근할 수 있다. this는 생략이 가능하다. 과거에는 명시적으로 보이지 않아 멤버 변수 접근시 항상 this를 사용하는 코딩 스타일이 존재했다. 그러나 최근엔 IDE의 발달 덕분에 멤버변수와 지역변수 구분이 잘되기 때문에, 꼭 필요한 경우에만 사용하고 생략하는게 권장된다. 변수 탐색 변수를 찾을 때 가까운 지역변수(매개변수 포함)를 먼저 찾고 없으면 그 다음으로 멤버변수를 찾는다. 멤버변수도 없으면 오류가 발생한다. 생성자 규칙 생성자의 이름은 클래스 이름과 같아야 한다. 반환타입이 없으므로 비워둬야 한다. 나머지는 메서드와 동일 인스턴스 생성 후 즉시 호출된다. new 키워드 이후 ()는 생성자 호출을 의미한다. 생성자 덕분에 자동 초기화로 인한 더미 데이터 생성을 방지하여 초기화를 강제할 수 있다. 기본 생성자 public class MemberInit { // 기본 생성자 public MemberInit() { } } 매개 변수가 없는 생성자 따로 정의한 생성자가 없는 경우 자바 컴파일러가 매개변수와 코드가 없는 기본생성자를 자동으로 만들어 준다. 생성자 오버로딩 생성자도 메서드 오버로딩처럼 여러 생성자 제공 가능 public class MemberConstruct { String name; int age; int grade; //추가 MemberConstruct(String name, int age) { this.name = name; this.age = age; this.grade = 50; } MemberConstruct(String name, int age, int grade) { this.name = name; this.age = age; this.grade = grade; } } this() 생성자 내부에서 자신의 생성자를 호출할 수 있다. (중복 제거를 위해) 단, this()는 생성자 코드 첫줄에만 작성할 수 있다. (아니면 컴파일 오류 발생) public class MemberConstruct { String name; int age; int grade; MemberConstruct(String name, int age) { this(name, age, 50); //변경 } MemberConstruct(String name, int age, int grade) { this.name = name; this.age = age; this.grade = grade; } } 절차 지향 프로그래밍 VS 객체 지향 프로그래밍 절차 지향 프로그래밍 프로그램의 흐름을 순차적으로 따르며 처리하는 방식 데이터와 기능이 분리되어 있다. 데이터와 기능의 분리는 유지보수 관점에서 관리 포인트가 2곳으로 늘어난다. 객체 지향 프로그래밍 객체들 간의 상호작용을 중심으로 프로그래밍하는 방식 (실제 세계의 사물이나 사건을 단순하게 추상화) 속성과 기능(메서드)이 객체 안에 함께 포함되어 있다. (캡슐화) 장점 객체 사용자의 입장에서 코드가 보다 친숙하고 가독성이 높다. 유연하고 변경이 용이하다. (OCP 원칙을 지키는 확장 가능한 설계) 실세계를 역할(인터페이스)과 구현(구현한 클래스 혹은 객체)으로 구분 (다형성) 클라이언트 코드를 변경하지 않고 서버의 구현 기능을 변경할 수 있다. (= 클라이언트는 인터페이스만 알면 내부 구조를 몰라도 되고 내부 구조를 변경해도 영향을 받지 않는다.) 한계 인터페이스가 변하면 클라이언트, 서버 모두 큰 변경이 발생한다. 따라서 인터페이스를 안정적으로 잘 설계하는 것이 중요하다. 캡슐화(Encapsulation) 속성과 기능을 하나로 묶어서 꼭 필요한 기능만 메서드를 통해 외부에 제공하고 나머지는 모두 내부로 숨기는 것 속성과 기능 묶기 + 접근 제어자를 통해 실현 좋은 캡슐화 속성은 반드시 숨기자. 객체의 데이터는 객체가 제공하는 기능인 메서드를 통해서 접근해야 한다. 데이터를 외부에 열어두면 클래스 내 데이터를 다루는 로직을 무시하고 데이터를 변경할 수 있음 꼭 필요한 기능만 노출하자. 클래스 내부에서만 사용하는 기능들은 모두 감추는 것 좋다. 사용하는 개발자 입장에서 필요한 기능만 정리되어 복잡도가 낮아진다. 음악 플레이어 예제 메소드 추출 팁 자신이 가진 데이터로 계산한다면, 일반적으로 자기자신이 메서드로 계산하는게 좋다. 나중에 수정이 생기거나 변경이 생길 때 본인만 바꾸면 되므로 관리가 편하다. 접근 제어자 해당 클래스 외부에서 특정 필드나 메서드에 접근하는 것을 허용하거나 제한할 수 있다. 필드, 메서드, 생성자에 사용된다. 지역변수는 스코프 내에서만 사용하므로 접근제어자를 사용하는 의미가 없고 사용할 수도 없다. 클래스에는 일부만 사용가능하다. (public, default) public 클래스는 반드시 파일명과 이름이 같아야 한다. 하나의 자바 파일에 public 클래스는 하나만, default 클래스는 무한정 만들 수 있다. 종류 private: 모든 외부 호출을 막는다. default(package-private): 같은 패키지안에서 호출은 허용한다. protected: default + 다른 패키지여도 상속 관계의 호출은 허용한다. public: 모든 외부 호출을 허용한다. 상속(Inheritance) extends 기존 부모 클래스의 필드와 메서드를 새로운 자식 클래스에서 재사용하는 것 중복을 줄이고 편리하게 확장할 수 있음 단일 상속만 할 수 있다. (다중 상속은 불가능) 만일, 두 부모를 상속받았는데 둘 다 move()라는 메서드를 가지고 있다면 어떤 메서드를 실행해야할지 애매하다. (다이아몬드 문제) 클래스 계층구조가 매우 복잡해질 수 있다. 메서드 오버라이딩 상속 받은 기능을 자식이 재정의하는 것 멤버변수는 오버라이딩되지 않는다. @Override 메모리 구조 상속관계 객체 생성 시 그 내부에 부모와 자식이 모두 생성된다. (하나의 참조값에 두 클래스 정보가 공존) 상속관계 호출시 대원칙 (3개) 상속관계 객체 호출 시, 호출자의 타입을 기준으로 먼저 찾는다. 현재 타입에서 기능을 찾지 못하면 상위 부모 타입으로 기능을 찾아서 실행한다. (끝까지 올라가도 없으면 컴파일 오류 발생) 자식 클래스에 오버라이딩된 메서드가 있다면 항상 우선하여 호출된다. Car와 ElectricCar 예제 super 상속관계에서 부모와 자식의 필드 이름과 메서드 이름이 같은 경우, 부모를 참조하고 싶을 때 super를 통해 부모 클래스로 접근한다. 생성자 상속관계를 사용하면 자식 클래스의 생성자와 부모 클래스의 생성자를 반드시 호출해야 한다. 상속 시 생성자 첫 줄에 super()를 사용해 부모 클래스 생성자를 호출해야 한다. 예외로 첫 줄에 this()(=나말고 다른 생성자를 호출해줘)를 사용할 수 있다. 그러나 자식 생성자 내에서 언젠간 super()가 호출되어야 한다. 부모 클래스의 생성자가 기본생성자라면 super()를 생략할 수 있다. 결과적으로 상속관계 생성자 호출은 부모에서 자식 순으로 실행된다. 다형성(Polymorphism) 다른 타입의 객체를 하나인 것처럼 처리해 주는 것 (아래 두가지 특성 덕분에 실현됨) (= 한 객체가 여러 타입의 객체로 취급될 수 있는 것) 다형성의 본질은 인터페이스를 구현한 객체 인스턴스를 실행 시점에 유연하게 변경할 수 있다는 것 다형적 참조 부모는 자식을 품을 수 있다. (부모 타입의 변수가 다양한 자식 인스턴스를 참조할 수 있다.) Parent poly = new Child() = 업캐스팅 (업캐스팅은 생략이 가능하고 권장된다.) 업캐스팅은 메모리상에 인스턴스가 항상 존재하므로 안전하다. 반면에, 자식은 부모를 품을 수 없다. Child child = poly // 컴파일 에러 만약 부모 클래스에서 자식 클래스의 메서드를 호출하고 싶다면 다운캐스팅 해야한다. Child child = (Child) poly ((Child) poly).childMehtod() (일시적 다운 캐스팅도 가능) 다만, 다운캐스팅은 자식 타입이 메모리상에 존재하지 않을 경우 ClassCastException 런타임 에러를 발생시키므로 매우 주의가 필요하다. 다운 캐스팅 시 instance of를 사용하면 안전하다. 오른쪽에 있는 타입에 왼쪽에 있는 인스턴스 타입이 들어갈 수 있으면 true, 아니면 false new Parent() instanceof Parent // true new Child() instanceof Parent // true new Parent() instanceof Child // false 자바 16부터는 instanceof와 동시에 변수 선언도 가능하다. if (parent instanceof Child child) {...} 다형적 참조 덕분에 자식 인스턴스들을 함수의 부모 타입 매개변수로 참조하거나, 배열의 타입을 부모 타입으로 가져가 자식 인스턴스들을 참조할 수 있다. (중복 제거 및 반복 가능) 메서드 오버라이딩 오버라이딩된 메서드는 항상 우선권을 가진다. 자식에서도 오버라이딩하고 손자에서도 오버라이딩했다면, 손자의 오버라이딩 메서드가 우선권을 가진다. 만일 메서드 오버라이딩이 없다면 항상 부모 타입의 메서드를 호출했을 것이다. 다형성 덕분에 IoC, OCP, DIP, 전략 패턴 등이 가능해짐 다형성이 매우 중요하다. OCP 원칙 좋은 객체 지향 설계 원칙 중 하나 Open for extension, Closed for modification (확장에는 열려있고 변경에는 닫혀 있다) 기존의 코드 수정 없이 새로운 기능을 추가할 수 있다는 의미 다형성을 보완하는 추상 클래스 추상 클래스는 다형성만으로 생기는 두 가지 문제를 해결한다. 부모 클래스를 인스턴스로 생성할 수 있는 문제 (추상적인 개념이 실제로 존재하는 것은 이상함) 부모 클래스를 상속 받는 자식 클래스가 메서드 오버라이딩을 하지 않을 가능성 (개발자의 실수) 추상 클래스 부모 클래스는 제공하지만 실제 생성되면 안되는 클래스 추상적인 개념을 제공하며 부모 클래스 역할로서 상속 목적으로 사용 인스턴스를 생성할 수 없음 (제약 1) abstract class AbstractAnimal {...} 추상 메서드 자식 클래스가 반드시 오버라이딩해야 하는 메서드 (제약 2) 메서드 바디가 없음 추상 메서드가 하나라도 있는 클래스는 추상 클래스로 선언해야 한다. public abstract void sound() 인터페이스 - 순수 추상 클래스를 지원 인터페이스 등장 배경 추상 클래스는 여전히 자신의 메서드를 가질 수 있다. 반면에, 순수 추상 클래스는 추상 클래스를 실행 로직이 전혀 없는 추상 메서드로만 구성한 것을 의미한다. 이는 다형성을 위한 규격, 마치 USB 인터페이스 같은 느낌을 준다. 자바는 이러한 순수 추상 클래스를 편리하게 사용할 수 있도록 인터페이스를 지원한다. 특징 interface 키워드, 구현시 implements 키워드 사용 인터페이스의 메서드는 모두 public abstract이다. (직접 쓸 수도 있지만 생략 권장) 인터페이스의 멤버 변수는 public static final이다. (마찬가지로 생략 권장) 구현이라는 용어 사용 상속은 부모의 기능을 물려 받는 것이지만, 인터페이스는 모든 메서드가 추상 메서드이므로 물려받을 기능이 없고 오히려 자식이 오버라이딩해서 메서드를 구현해야 한다. 다만, 자바 입장에서는 상속이나 구현이나 동일하게 동작한다. 클래스 & 추상 클래스 & 인터페이스는 코드와 메모리 구조상 모두 동일하다. 다중 구현을 지원 유용한 이유 제약 인터페이스의 메서드를 반드시 구현하라는 규약을 준다. 순수 추상 클래스를 지향해도 추상 클래스는 다른 개발자가 미래에 메서드를 추가할 수 있기 때문에, 인터페이스는 이를 예방한다. 다중 구현 클래스의 상속이 하나의 부모만 지정할 수 있는 것과 달리, 인터페이스는 여러 부모를 둘 수 있다. 인터페이스는 자신이 구현을 가지지 않고, 자식이 메서드를 구현한다. 또한 어차피 오버라이딩으로 인해 자식의 메서드가 호출된다. 따라서, 다이아몬드 문제가 발생하지 않는다. 실무적 장단점 인터페이스는 기획이나 사용 기술이 구체화되지 않았을 때, 구현을 미룰 수 있다. (장점) 어떤 DB를 사용할지 미정이라면, 인터페이스만 구현 후 메모리 레포지토리를 사용 할인 정책이 미정이라면, 인터페이스만 구현 후 0원 할인으로 미리 개발 가능 인터페이스는 추상화라는 비용을 발생시킨다. (단점) 개발자가 코드를 읽을 때 인터페이스를 항상 본 후 구현체를 보게 되어 읽는 시간이 증가한다. 대부분 모든 곳에 인터페이스를 먼저 구현하는 것이 이상적이지만, 기능을 확장할 가능성이 없다면 구체 클래스를 직접 사용하고 향후 꼭 필요할 때 리팩토링해서 인터페이스를 도입하는 것도 좋다. 의존 관련 용어 정리 A -> B (UML) = A가 B를 안다. = A가 B를 의존한다. = A가 B를 상속받았다. (A가 자식이고 B가 부모다) = A가 B를 사용한다. 좋은 객체 지향 설계의 5가지 원칙 (SOLID) 클린 코드 저자 Robert Martin(로버트 마틴)은 좋은 객체 지향 설계의 5가지 원칙을 제시한다. 단일 책임 원칙(SRP, Single responsibility principle) 한 클래스는 하나의 책임만 가져야 한다. 책임의 추상적인 표현이지만, 변경을 기준으로 파급 효과가 적으면 단일 책임 원칙을 잘 따른 것 개방-폐쇄 원칙(OCP, Open/closed principle) 소프트웨어 요소는 확장에는 열려 있으나 변경에는 닫혀 있어야 한다. 다형성을 활용해 기존 코드는 변경하지 않고 새로운 기능들을 추가할 수 있다. 리스코프 치환 원칙(LSP, Liskov substitution principle) 프로그램의 객체는 프로그램의 정확성을 깨뜨리지 않으면서 하위 타입의 인스턴스로 바꿀 수 있어야 한다. 다형성의 하위 클래스는 인터페이스 규약을 다 지켜야 한다는 것 다형성에 신뢰성을 부여하고 지원하는 원칙 예시 자동차 인터페이스의 엑셀은 앞으로 가야하는 기능인데, 뒤로 가게 구현하면 LSP 원칙 위반 느리게 가더라도 앞으로 가야한다. 인터페이스 분리 원칙(ISP, Interface segregation principle) 특정 클라이언트를 위한 인터페이스 여러 개가 범용 인터페이스 하나보다 낫다. 인터페이스가 명확해지고 대체 가능성이 높아진다. 예시 자동차 인터페이스 -> 운전 인터페이스 & 정비 인터페이스로 분리 사용자 클라이언트 -> 운전자 클라이언트 & 정비사 클라이언트로 분리 정비 인터페이스가 변해도 운전자 클라이언트에 영향을 주지 않음 의존 관계 역전 원칙(DIP, Dependency inversion principle) 프로그래머는 추상화에 의존해야지, 구체화에 의존하면 안된다. 즉, 클라이언트 코드가 구현 클래스에 의존하지 말고 인터페이스에 의존하라는 의미 다만, 다형성만으로는 OCP, DIP 원칙을 지킬 수 없다. OCP, DIP를 지키려고 하다보면 결국 스프링 프레임워크를 만들게 된다. Reference 김영한의 실전 자바 - 기본편 스프링 핵심 원리 - 기본편

Java-Ecosystem · 2024-02-06

자바 메모리 구조와 변수, 메서드 종류

자바 메모리 구조 메서드 영역 프로그램을 실행하는데 필요한 공통 데이터를 관리 프로그램의 모든 영역에서 공유됨 구성 클래스 정보: 클래스 실행 코드 (바이트 코드) - 필드, 메서드, 생성자 코드 등 static 영역: static 변수, 메서드, 클래스들을 보관 (프로그램 시작부터 끝까지 메모리 할당) 런타임 상수 풀: 프로그램을 최적화하기 위해 공통 리터럴 상수를 보관 스택 영역 실제 프로그램이 실행되는 영역 실행 스택을 생성하고 메서드가 호출될 때마다 스택에 스택 프레임을 쌓는다. 메서드가 종료되면 스택프레임을 제거한다. 지역변수, 중간 연산 결과, 메서드 호출 정보 등이 스택 프레임에 포함된다. 처음 자바를 실행하면 main()을 실행하기 위해 실행 스택에 main() 스택 프레임을 하나 생성한다. 힙 영역 인스턴스가 생성되는 영역 (new 명령어를 사용하면 여기를 사용) 가비지 컬렉션이 이루어지는 영역이며, 더 이상 참조되지 않는 객체는 GC에 의해 제거된다. 메서드 코드의 위치 객체가 생성될 때, 인스턴스 내부 변수 값은 각각 힙 영역에 할당되어 독립적으로 존재하지만, 메서드는 새로운 메모리 할당없이 공통된 코드를 공유한다. 따라서, 인스턴스 메서드를 호출하면 실제로는 메서드 영역에 있는 코드를 힙 영역으로 불러와서 수행한다. 단, static 메서드는 메서드 영역의 클래스 정보 코드를 사용하겠지만, 실행도 메서드 영역의 클래스 정보에서 한다. 멤버 변수의 종류 인스턴스 변수 (static이 붙지 않음) 각각의 인스턴스에 독립적으로 소속되어 있는 변수 static 변수 (static이 붙음) 클래스 자체에 소속되어 공용으로 함께 사용할 수 있는 변수 static 변수 = 정적 변수 = 클래스 변수 메서드 영역 (static 영역)에서 관리 클래스명 + . 으로 접근 (자신의 클래스에 있는 정적 변수라면 클래스명 생략 가능) 처음 자바가 로딩될 때 하나만 생성 일반적으로 자바 프로그램이 실행되고 JVM이 처음 뜰 때, 클래스 정보를 메소드 영역에 모두 불러 들이고, static이 붙은 변수들은 메모리(static 영역)에 할당해버린다. 이런 static 변수들은 이 때 딱 하나 만들어지고 Java가 끝날 때까지 계속 쓸 수 있다. 변수의 생명주기 지역변수(매개변수 포함): 스택 영역의 스택 프레임에 존재 (메서드 종료 시 소멸) 인스턴스 변수: 힙 영역에 존재 (GC 발동 시 소멸) 클래스 변수: 메서드 영역의 static 영역에 존재 (JVM 종료 시 소멸) 지역변수 < 인스턴스 변수 < 클래스 변수 지역 변수가 제일 짧고, 클래스 변수가 제일 길다. static이 정적인 이유 힙 영역에 생성되는 인스턴스 변수는 런타임에서 동적으로 생성되고 제거되지만, static 변수는 프로그램 시작 시점에 만들어지고 프로그램 종료 시점에 제거되므로 상대적으로 매우 정적이다. 멤버 메서드의 종류 인스턴스 메서드 (static이 붙지 않음) 인스턴스에 소속되어 인스턴스를 생성해야 사용할 수 있는 메서드 static 메서드 (static이 붙음) 클래스에 소속되어 클래스에 바로 접근해 사용할 수 있는 메서드 static 메서드 = 정적 메서드 = 클래스 메서드 인스턴스 변수를 필요로 하지 않는 단순 기능만 제공하는 경우 사용 (유틸리티성 메서드) static 메서드는 static만 사용할 수 있다.(정적변수나 정적 메서드) main()가 대표적 정적 메서드 (main()이 같은 클래스에서 호출하는 메서드도 정적 메서드) 자주 호출해야 한다면 static import를 통해 클래스 명을 생략하고 메서드를 호출할 수 있다. final 변수에 final 키워드가 붙으면 더는 값을 변경할 수 없다. 특정 변수의 값을 할당한 이후 변경하지 않아야 한다면 사용하자. (고객 id 같은 부분) 의미 있는 경우 static final 필드(클래스 멤버 변수)를 필드 초기화 하는 것 (메모리 중복 없음) 상수도 static final을 지정한다. 생성자를 이용해서 final 필드(인스턴스 멤버 변수)를 초기화 하는 것 의미 없는 경우 final 필드(인스턴스 멤버 변수)를 필드 초기화 하는 것 (인스턴스마다 값이 중복되어 메모리 낭비) 클래스 final 상속의 끝을 의미, final로 선언된 클래스는 상속할 수 없다. 메서드 final 오버라이딩의 끝을 의미, final로 선언된 메서드는 오버라이드 될 수 없다. Reference 김영한의 실전 자바 - 기본편

Java-Ecosystem · 2024-02-06

IntelliJ 단축키 정리

자동완성 계열 iter For Each Syntax sout println soutv println + 원하는 변수 soutm 현재 클래스와 메소드 이름을 출력한다. 리팩토링 계열 command + shift + T 클래스 지정하면 그에 대한 테스트 틀 생성 command + shift + 위/아래 위/아래 메서드와 위치 변경 (메서드에 커서 선택 후 진행) command + shift + 8 Column Selection Mode (여러 라인 동시 수정 가능) command + n 파일 혹은 코드 생성 command + option + N Inline variable로 리팩토링 command + option + V 변수 추출 및 추천 (Introduce variable) command + option + M 메소드 추출 및 추천 command + option + shift + L 파일 코드 재정렬 option + Enter Context에 따른 가능 액션 종류를 보여줌 (create method, create class 등) 자동 import, static import(Add on-demand static import) 지원 option + option + 위/아래 Multi-line select option + shift + click Specific line select ctrl + T 리팩토링 ctrl + O 오버라이드 shift + F6 클래스, 변수, 파라미터 이름을 일괄적으로 변경 유틸 계열 command + B 코드가 사용된 모든 곳들을 추적 command + option + B 해당 인터페이스의 모든 구현체들 추적 command + P 파라미터 정보 제공 command + E 과거 행동 이력 및 이전 파일 이동 command + O Navigate shift X 2 Search (Navigate과 유사) ctrl + R 바로 이전 것 실행 ctrl + shift + R 클래스 레벨 실행 option + ↑ 범위 블록 설정 F2 오류가 발생한 곳으로 커서 이동 command + 숫자 0 Commit 1 프로젝트 디렉토리 영역 혹은 코드 작업 영역 선택 4 Run window 5 Debug window 6 Problems 9 Git log command + F_number F12 해당 클래스의 멤버 변수, 메서드, 상속 클래스 등의 전체 정보 보기

Java-Ecosystem · 2024-02-05

자바 주요 syntax 정리

Java-Ecosystem · 2024-01-28

Java 기본 특징

자바 표준 스펙 자바는 표준 스펙이 존재하고 여러 회사가 자신에 입맞에 맞게 이를 구현한다. 자바 표준 스펙 자바의 설계도 문서 자바 커뮤니티 프로세스(JCP)를 통해 관리 구현 자바 표준 스펙에 맞춰 여러 회사가 각자에 최적화된 자바 프로그램을 개발 오라클 Open JDK, Adoptium Eclipse Temurin, Amazon Corretto etc… 오라클 Open JDK 사용하다가 Amazon Corretto 사용해도 대부분 큰 문제 없음 각 회사들은 다양한 OS(Mac, Windows, 리눅스)에 맞는 자바도 함께 제공 컴파일과 실행 소스코드(Source code) 개발자가 .java 확장자의 자바 소스코드를 작성한다. 컴파일(Compile) 단계 자바가 제공하는 javac 를 사용해, .java -> .class 파일 생성 command: javac Hello.java 즉, 자바 컴파일러가 소스코드를 바이트 코드로 변환 자바 가상 머신에서 더 빠르게 실행될 수 있게 최적화하고 syntax error 검출 실행(Runtime) 단계 java 프로그램을 사용해 자바를 띄우고 바이트코드인 .class 파일을 실행하면, JVM(실제 자바 프로그램 = 자바 가상 머신)이 띄워지면서 바이트코드를 읽고 프로그램을 실행한다. command: java Hello (Hello.class 의 .class 확장자를 빼고 입력) 운영체제 독립성 일반적인 프로그램은 다른 운영체제에서 실행할 수 없다. Windows 프로그램은 Windows OS가 사용하는 명령어들로 구성되어 있어서, 다른 OS와 호환되지 않음. 반면에, 자바 프로그램은 자바가 설치된 모든 OS에서 실행 가능 (호환성) 각 OS에 맞게 설치된 자바는 해당 OS의 명령어들로 컴파일된 .class 바이트코드를 실행 덕분에 개발할 때와 서버 실행 시 환경에 맞춰 다른 자바를 사용할 수 있다. 개발: Mac, Windows 서버: AWS Linux (Amazon Corretto 자바 설치) Reference 김영한의 자바 입문 - 코드로 시작하는 자바 첫걸음

Java-Ecosystem · 2024-01-28

Lucian Log

Contact

Java-Ecosystem