Spring

java SpringBean DI ComponentScan

java 테스트케이스 작성, 간단한 회원관리 예제

springBoot체험

데이터 베이스 적용 H2 DataBase 적용 스프링 부트 데이터베이스 연결 설정 추가 리포지토리 개선 현재 실습에서 사용 중인 리포지토리는 MemberRepository 인터페이스를 구현한 MemoryMemberRepository이다. 이 구현체는 DB나 파일을 사

spring 회원, 주문관리 예제 만들기

SpringContainer Bean

Singleton

Bean Scope

servlet

custom MVC architecture

spring MVC

Logging 운영시스템에서는 System.out.println()같은 시스템 콘솔을 사용하지 않그 별도의 로깅 라이브러리를 이용한다. 스프링 부트의 기본 logging 라이브러리는 인터페이스로 slf4j, 구현체로는 Logback을 이용한다. 사용은 여러가지 방식이

요구사항 분석 상품 도메인 모델 상품 ID 상품명 가격 수량 상품 관리 기능(CRUD) 상품 목록 상품 상세 상품 등록 상품 수정 서비스 제공 흐름 실제 상황을 가정하면, 디자이너는 요구사항에 맞추어 디자인 결과물을 웹 퍼블리셔에게 넘겨준다. 웹 퍼블리셔는 받은 디자인을 기반으로 HTML, CSS를 작성하여 개발자에게 전달한다. 백엔드 개발자는 HTM...

thymeleaf

th:object , th:field 컨트롤러의 메서드에서 model을 주입받아 빈 Item 객체를 추가한 후, 이를 템플릿으로 전달하면 타임리프 템플릿 엔진은 해당 객체를 바탕으로 화면을 렌더링하게 된다. 이 방식은 주로 form의 초기 값이나 빈 입력 필드를 제공하기 위해 사용된다. GET 요청에 대해 템플릿을 반환할 때 컨트롤러에서 미리 빈 객체를...

메세지 span태그 안에 들어있는 "메인 페이지로 이동"과 같은 하드코딩된 부분에 대한 수정 요구사항이 추가될 경우 그냥 바꿔주면 되는 것 아닌가 생각할 수 있지만, 큰 프로젝트에서 이러한 단어가 여러 템플릿 파일에 중복되어있을 경우 매우 많은 작업이 있을 것이다.

Spring Controller Validation(Field Object)

짜증, 부담, 복잡 Validator 사용으로 컨트롤러 메서드에서의 코드 복잡도는 내려갔다. 대신 우리는 컨트롤러 클래스의 새로운 메서드로 를 추가해야했고 Validator Class를 직접 구성해야 했다. 귀찮음의 본질은 결국 다음의 검증로직이다. 결국 위의 코드

session, session login, cookie

servlet filter, spring interceptor

SpringMVC errorPage

예외처리

타입 컨버터

spring start

관심사 분리, DI container, Configuration, Bean

Spring ComponentScan

Spring Auto DI

빈 생명주기 콜백, 초기화/생성자,DI

refresh~

Servlet, JSP

스프링 파일 업로드

커넥션풀, Jdbc, DataSource

트랜잭션(transaction) 데이터를 DataBase에 저장하는 가장 대표적인 이유는 DB가 가진 transaction기능 때문이다. 직역하면 "거래"라는 뜻의 트랜잭션은 하나의 거래를 안전하게 처리하도록 보장해준다. 하나의 거래가 성공적으로 처리되려면 생각보다 고려해야할 점이 많다. "kim이 song에게 50000원의 송금 거래" 위의 거래 행위...

트랜잭션 구현 문제점 컨트롤러를 관리하는 컨트롤러 클래스의 핸들러 메서드는 웹 계층에서 클라이언트의 요청을 처리하고, 응답을 생성하는 책임을 진다. 구체적인 처리 과정인 비즈니스 로직은 다시 서비스 계층을 호출하여 해결한다. 서비스 계층에는 비즈니스 로직을 가지며 DB와의 연결을 통해 데이터를 주고 받기 위해 서비스계층은 다시 리포지토리 계층을 활용한다. ...

SQLException 짧고 직관적인 우리의 비즈니스 로직 코드가 완성되었다. 하지만 여전히 이 코드는 Jdbc에 의존적이다. Jdbc 라이브러리로부터 온 SQLException때문이다. 정확히는 위 메서드는 SQLException를 던져주고 있다.(던져야만 한다)

JdbcTemplate JdbcTemplate는 설정이 편리하며 템플릿 콜백 패턴을 사용하여 Jdbc를 직접 사용할 때 발생하는 대부분의 반복 작업의 문제를 해결해준다. 우리는 SQL을 작성하고, 파라미터를 정의하고, 응답 값(ResultSet)을 매핑하기만 하면 된다

transaction for independent test

mybatis

jpa, spring data jpa, querydsl

@Transaction은 편리한 트랜잭션 적용을 가능케 하지만 트랜잭션 관련 코드가 눈에 보이지 않는다. basicService에는 @Transaction이 존재한다. 애노테이션이 메서드레벨 혹은 클래스레벨에 적용되었을 때 스프링은 basicService의 대한 주입을

transaction propagation

build.gradle, application.yml

엔티티 설계

service, repository 구현

주문 비즈니스 로직

회원 등록 템플릿으로 엔티티의 데이터를 전달하기 위해 엔티티 객체를 직접 사용해서 View계층으로 전달하는 것은 옳지 않다. View와 Controller 계층 사이에서 Validation과 같은 여러 추가 작업이 발생할 수 있으며, 필요없는 필드가 왔다갔다하는 것은 굉장히 비효율 적이기 때문이다. 또한 엔티티가 View계층에 종속적으로 변할 경우 화면에서...

영속성 컨텍스트

@Entity JPA의 시작이라고 볼 수 있는 엔티티를 설정하기 위해 클래스에 @Entity 애노테이션을 붙여 JPA가 관리할 수 있도록 한다. 기본 생성자 필수(public or protected) final, enum, interface, inner 사용 불가 DB에 저장할 필드 final 사용 불가 속성 name으로 하여금 엔티티 이름 따로 설정가...

객체와 테이블간의 개념적 괴리 Member와 Team은 N:1 관계이다. 한 팀의 여러 멤버가 존재할 경우를 DB 테이블화 한다면 두 개의 테이블로 외래키를 Member쪽에 두어 TEAMID 컬럼을 두고 이를 foreignkey로 team의 id와 연결할 수 있다.

연관관계 매핑 심화

em.find() vs em.getReference() 이미 잘 쓰고있는 em.find(entity) 내부 동작 메커니즘은 다음과 같다. 영속성 컨텍스트에 entity 서치 -> 존재한다면 반환 (쿼리 X) 영속성 컨텍스트에 없을 경우 DB 서치 -> 존재한다면 반환 (쿼리 O) + 영속성 컨텍스트에 조회대상 엔티티 안착시킴 em.getReference...

값 타입

jpql

jpql

DTO

주문 API

V1 엔티티 직접 노출 가장 초보적인 방식이다. 이 경우 orderItems와의 일대다 다대일 양방향 연관관계에 의해 무한 루프에 걸리게 되는데 이를 해결하기 위해 한쪽의 엔티티 연관관계 필드에 @JsonIgnore를 걸어야 한다. 엔티티에 수정이 들어가게 되어 이

기본 기능 중복 문제 Repository에 기본적으로 작성해놓는 CRUD기능들은 코드 형태가 대부분 동일하다. 위의 예시는 save만 보였지만 delete나 findById, findAll과 같은 CRUD관련 메서드들 또한 엔티티에 따라 달라지는 점이 크지 않다. Spring Data JPA의 유용한 기능중 하나는 이러한 중복 문제를 해결해준다는 것이다...

사용자 정의 리포지토리 구현 Spring Data Jpa를 기본으로 사용할 때, Querydsl과 같은 기술을 이용해 복잡한 메서드를 추가하고 싶을 수 있다. 하지만 위의 코드를 보면 MemberRepository(Spring Data Jpa)는 인터페이스이기 때문에 메서드 로직 작성이 불가능하다. 직접 구현을 위해 다음과 같은 과정을 거친다. 사용자 ...

환경설정(spring boot 3) boot2에 비해 매우 간편해졌는데, 위의 정보만 build.gradle의 dependencies에 추가해주고 빌드만 다시 해주면 Q타입 생성이 자동적으로 잘 이루어진다. Q-Type querydsl 문법 사용을 위해 엔티티 객체가 아닌 엔티티와 매핑되어 자동으로 생성된 Q-Type의 객체를 가져와야 한다. 사용할 ...

DTO projection 결과를 DTO로 반환할 때 다음과 같은 3가지 방법이 존재한다. 프로퍼티 접근(Setter) 필드 직접 접근 생성자 사용 단순히 jpql을 사용할 때 DTO 적용시 매우 지저분한 모습을 볼 수 있다. DTO의 경로를 모두 String으로 정확히 입력해야하기 때문이다. 프로퍼티 접근 Dto를 사용하기 위해 Projections...

사용자 정의 Repository spring data jpa와 querydsl을 하나의 리포지토리에서 사용할 수 있도록 다음의 구조로 설계 한다. 이전에 배웠던 사용자 정의 repository 방식이며 현재 hibernate 버전에서는 이름 규칙으로 적은MemberRepositoryImpl을 MemberRepositoryCustomImpl도 허용하고 있...

밑바닥 부터 이때동안 모든 실습에 있어 스프링 부트를 활용해왔다. 스프링 부트는 톰캣 WAS를 내장하고있고 개발자는 코드를 작성해서 실행하기만 하면 WAS가 함께 실행되었다. 부트가 없던 옛날 스프링 개발자들은 직접 WAS를 설치하고 war를 만들어 WAS에 배포하는 과정이 필요했었고 이를 직접 경험해보자 한다. Tomcat 설치 다운로드 링크 (스프링...

WAR 배포 방식의 단점 톰캣을 직접 깔고 애플리케이션을 WAR로 빌드하여 톰캣에 이를 전달하는 등 과거에는 당연했지만 이는 현재의 부트 환경에서는 매우 불편한 방식이다. 단순한 자바 어플리케이션이라면 main() 하나만으로 어플리케이션이 올라간 웹 서버 실행할 수 있기에 현재의 부트환경에서의 스프링 개발자들은 매우 편리하게 개발을 하고 있다. 결국 톰...

library autoConfiguration

외부 설정의 필요성 어플리케이션을 개발할 때에 보통 로컬-개발-테스트-운영 등의 환경이 존재한다. 개발 환경과 운영환경에서 사용하는 DB가 다르므로 각 DB url을 환경마다 다르게 설정해주어야 한다. 각 환경에 맞는 설정을 내부에 포함하여 빌드한 파일로 그에 맞는 서버에서 실행시킬 수 있다.(오래된 방식) 이러한 방식은 환경에 따라 여러번의 빌드가 필...

환경설정 객체 application.properties에 들어갈 외부설정은 위와 같다. 이를 읽을 방법으로, 우리는 스프링의Environment 인터페이스를 활용했었다. 스프링이 지원하는 다른 방법들이 존재하는데 애노테이션 방식인@ConfigurationProperties로 하여금 더 편리한 이용이 가능하다. 환경설정 객체 빈 등록 Config MyD...

프로덕션 준비 기능 애플리케이션을 실제 운영 단계(production level)에서 가동할 때에 기능이 적절히 돌아가는 것만큼 중요한 사항이 지속적인 모니터링이다. 애플리케이션이 현재 살아있는지, 로그가 잘 찍히고 있는지, 서버 하드웨어 리소스가 어느정도 부하로 이용되고 있는지 지속적으로 확인해야 한다. 이러한 비기능적 기능을 프로덕선 준비 기능이라고 한...

모니터링 툴 스프링을 학습하며 가장 눈이 즐거울 학습이 될 것이다. 학습의 궁극적 목표는 항상 서버기술에 대한 것이므로 웹 실습에서 UI는 단순화하고 내부 기술에 집중한다. 그에 따라 실습 결과물의 외모는 최악이다. 예쁘고 전문적으로 보이는 대시보드 UI는 항상 사막속 오아시스처럼 여겨진다. 위의 짤은 그라파나로 대시보드 툴이다. 설치해서 사용해야하며 ...

Custom Log 추적기 위의 복잡한 커스텀 로그 추적기가 존재한다. 이 로그 추적기를 Controller, Service, Repository의 모든 메서드에 심을 것이다. 위의 복잡한 로직을 파악하기보다는 핵심에 집중해보자. 위와 같이 로그를 직관적으로 보이게 하는 것이 목적이다. 컨트롤러가 호출하는 서비스, 서비스가 호출하는 리포지토리의 기능들...

커스텀 로그 추적기에 대한 불만 로그 기능을 붙이기 위해 주석처리된 한 줄의 비즈니스 코드 외의 로그와 관련된 코드를 작성해야 한다. 이를 모두 작성했다 하더라도 만약 로그 추적기가 변경된다면 로그 기능이 붙은 모든 메서드에 대해 수정이 불가피하다. 즉 위의 코드는

기존로직에 횡단관심사를 추가하는 것을 프록시 패턴으로 풀어내는 방법, 프록시 패턴이 가져다주는 이점과 여전히 해결하지 못한 것들 설명

동적 프록시

프록시 빈 등록 기존 문제 일반적인 Controller 객체가 존재하고, 우리는 이를 프록시로 우회적으로 빈 등록을 하기 위해 Config 클래스를 만들어 수동등록을 해야했다. 심지어는 등록 코드 자체가 매우 복잡해지는 것을 볼 수 있었고 컴포넌트 스캔이라는 편리한 등

Spring AOP 구현 가장 간단한 형태 :: @Aspect 당장은 어드바이스 선언의 파라미터에 해당하는 포인트컷 표현식에 대해서는 자세히 분석하지 않도록 한다. 대충 해당 표현은 order 디렉터리 안의 모든 클래스에 대해 AOP를 적용한다는 것이다. 일단 AO

Proxy 패턴의 내부 호출 문제 메서드 단위로 로그를 찍는 애노테이션 방식의 AOP(@MyLogging)를 설계했다고 가정하자. 본래의 의도대로라면 external()에서 한번 찍히고 external() 내부에 존재하는 internal()을 호출할 때 다시 AOP가 동작되어야 한다. 이 예시에서 프록시 패턴의 단점이 드러난다. 테스트로 단순히 위 빈...

본 포스팅은 JPA 엔티티 생성에 대해 생성자 방식이 아닌 빌더 패턴 적용을 전제로 한다. @Builder - @NoArgsConstructor 조합 JPA 엔티티를 구성하려 JPA 스펙에 따라 리플렉션 기술을 활용하기 위해 기본적으로 제어자가 protected혹은