I leaned/스프링,스프링부트

Open In View "Open in View"는 웹 애플리케이션에서 사용되는 개념으로, 데이터베이스의 트랜잭션을 뷰(View) 가 렌더링되는 시점까지 연장하는 것을 의미한다. 이 개념은 주로 ORM(Object-Relational Mapping) 프레임워크에서 사용된다. 전통적인 방식에서는 트랜잭션을 서비스(Service) 레이어에서 시작하고, 데이터 액세스 계층(DAO, Repository)에서 종료한다. 스프링부트에서는 @Transactional이 붙은 레이어(서비스)에서 트랜잭션이 시작되고, 서비스가 종 료될 때, 트랜잭션이 종료된다. 이것은 open in view를 false로 설정한 것과 동일하다. "Open in View"를 사용하는 경우 트랜잭션의 시작은 서비스이고, 트랜잭션의 종료도 서..

DTO Data Transfer Object"의 약어로, 데이터 전송 객체를 의미 DTO는 소프트웨어 시스템에서 데이터를 전송하거나 교환하는 데 사용되는 객체 일반적으로 DTO는 비즈니스 계층과 프레젠테이션 계층 사이에서 데이터 전달을 위해 사용된다. 비즈니스 계층은 데이터베이스나 외부 시스템과 상호 작용하여 데이터를 검색하거나 수정하는 작업을 수행 이러한 작업은 DTO를 사용하여 필요한 데이터를 프레젠테이션 계층에 전달하거나 외부 시스템으로 전송하는 데 사용될 수 있다. DB - Table - Model - DTO Model또는 Entity 또는 테이블을 노출시키지 않음 - 필요한 정보만 외부(프론트엔트)로 넘겨줌 DTO는 공유해서 사용하면 안된다. - API스펙이 바뀔경우 수정이 어렵다.

컨트롤러의 책임 클라이언트의 요청(값) 수신 Content-Type을 확인해서 application/json 이면 @RequestBody를 붙여준다. x-www-form-urlencoded 이면 DTO로 받아준다. 유효성검사(DB가 필요없는 모든 검사) DispatcherServlet이 @Valid 어노테이션과 Errors errors 매개변수를 작성해주면 자동으로 유효성 검사를 진행해주고, 유효성 검사가 실패하면 errors 변수에 에러를 담아준다. 잘못 받은 값에 대한 응답 AOP(관점지향 프로그래밍)처리하는 것이 좋다. 정상적으로 처리되었을 때 응답 서비스의 책임 DB연결 DTO 생성 비즈니스 로직 구현 서비스 레이어는 애플리케이션의 비즈니스 규칙을 구현합니다. 비즈니스 로직은 애플리케이션의 핵심 ..

DTO(Domain Transfer Object) 유효성 검사 소프트웨어 개발에서 DTO 객체의 데이터가 요구사 항에 맞는 유효한 값인지 확인하는 과정 DTO는 주로 데이터 전송을 위해 사용되는 객체로, 사용자 인터페이스(UI)와 비즈니스 로직 간의 데이터 전달을 담당. DTO 유효성 검사는 다음과 같은 목적을 가지고 수행된다. 데이터의 유효성 확인: DTO 객체의 데이터 필드에 입력된 값이 올바른 형식, 범위, 제약 조건 을 충족하는지 확인 ex) 숫자 필드에는 숫자 값이 입력되어야 하고, 문자열 필드 에는 특정 길이나 패턴이 적용되어야 한다. 비즈니스 규칙 준수 확인: DTO 객체의 데이터가 비즈니스 규칙을 준수하는지 검사 ex) 주문을 나타내는 DTO에서 수량 필드는 음수가 될 수 없고, 가격 필드..

N + 1 문제 연관관계가 설정된 엔티티 사이에서 한 엔티티를 조회하였을 때, 조회된 엔티티의 개수(N 개)만큼 연관된 엔티티를 조회하기 위해 추가적인 쿼리가 발생하는 문제를 의미 개인적으로 한 엔티티를 조회하는데 여러개의 쿼리가 나가는 것이니깐..1+N이 더 맞는 말이 아닐까하는 생각이 있다.. 한번의 쿼리로 가져올 수 있음에도 테이블 수 만큼의 쿼리가 나간다는 뜻 (물론 상황에 따라 좋을 수도 안좋을 수도 있다.) ex) 멤버와 팀 테이블이 있을 때 팀정보는 필요업속 멤버만 필요하다면 각각 나가는 것이 유리하다. 멤버와 팀 정보가 항상 같이 필요할 때는 쿼리가 한번만 나가는 것이 유리하다. Fetch join 과 일반Join 비교 일반 Join Fetch Join과 달리 연관 Entity에 Join을..

서버가 터지더라도 컨트롤러는 터지면 안된다. 컨트롤러는 입출력을 맡고 있기에 비즈니스 로직을 컨트롤러에 구현하면 컨트롤이 터지기 때문에 비즈니스로직을 따로 분리하여서 구현해야한다.

WebDataBinder 타입변환 : 타입이 불일치할 때 타입을 변환해서 BindingResult에 저장 (에러시 에러 저장), BindingResult는 데이터(예시에선 date) 바로뒤에 붙어 와야 한다. 데이터 검증 : month의 경우 1~12 같은 제약사항 검증 (에러시 에러저장) 타입변환 기본적으로 스프링에서 자동으로 변환을 해준다. 커스텀 변환기능을 추가 할 수 있다. 우선순위: 커스텀PropertyEditor, ConversionService, 디폴트PropertyEditor 순 또는 위에 처럼 @DateTimeFormat 에너테이션을 이용해서 필드에서 형식을 지정해줘도 됨, 숫자나 날짜는 많이 쓰여서 지원이 됨 PropertyEditor 양방향 타입 변환(String -> 타입 , 타입 ..

스프링부트에서는 Dispatcher서블릿등 앞단을 가렸다. 하지만 전체적인 구조는 알아야한다. 컨트롤러를 디스패처에서 관리하기 위해서는 리플렉션을 알아야 한다. 리플렉션을 통해 클래스타입을 통일시켜야한다. 리플렉션을 통해 다형성 DispatcherServlet 기본적으로 입력,처리,출력 서블릿이 여러개 존재한다 공통 처리 부분을 DispatcherServlet을 통해 제거한다. DispatcherServlet이 전처리를 해준다. Spring MVC의 요청처리과정 요청이 들어오면 DispatcherServlet은 HandlerMapping한테 해당 URL에 대한 Handler Method 정보를 받아온다. HandlerAdapter를 통해 DispatcherServlet와 Controller을 느슨한 연결..