전체 글

보호되어 있는 글입니다.

@SpringBootTest 와 @Test의 가장 큰 차이는 Bean 관리 주체입니다. @SpringBootTest는 컴포넌트(Component)로 등록된 빈(Bean)을 관리하는 스프링 컨텍스트(Spring Context)를 로드한 후 테스트를 검증하기 때문에, 스프링이 의존 관계를 연결(DI)할 수 있습니다. @Test는 이러한 스프링 컨텍스트의 사용 없이, 테스트를 검증하기 때문에, 의존 관계를 연결할 수 없어 개발자가 직접 의존관계가 있는 빈을 연결해줘야 합니다. @SpringBootTest 어노테이션을 달면, 스프링 컨텍스트를 로드한 후부터 테스트를 검증할 수 있습니다. 그래서 짧은 테스트 코드를 작성하였더라도, 레포지토리(Repository)가 존재한다면 Database까지 모두 정상적으로 연..

지금까지 저는 JPA가 Spring(이하 스프링)의 기술이라고 생각했습니닷! 그래서 아.. 스프링 못하니까 JPA는 어림도 없겠지.. 라며 엄두도 못냈었죠..ㅎㅎ 알고보니, JPA는 JAVA의 기술이었습니다!! Spring에서 사용하는 JPA는 Spring Data JPA인데 우리가 줄여서 JPA라 부르는 것일뿐..!그럼 JPA가 무엇인지, 어떻게 Database에 객체를 저장할 수 있는지 제가 이해한 것을 함께 나눠보도록 하겠습니다!JPA란 무엇인가JPA란 Java Persistence API의 축약어입니다.자바 Persistence API..? 자바 Persistence하는 API..? Persistence..? 이게 영속성인 것 같은데..사전을 찾아봤습니다.아, 영속이라는 말대신 지속이라는 말로 바..

자바 객체를 데이터베이스에 그대로 저장할 수 없기에, 우리는 스키마를 만들고, 테이블을 만들어 레코드 하나에 하나의 객체를 풀어 저장합니다.이는 직관적으로 알 수 있지만, 말로 설명하기가 어렵습니다. 왜 이렇게 다를까요? 그 이유는 자바와 데이터베이스의 패러다임, 즉 지향하는 관점이 다르기 때문입니다.자바는 객체 지향적이며, 데이터베이스는 데이터 중심의 관계지향적입니다. 그렇기 때문에, 우리는 데이터베이스에 자바 객체를 그대로 저장할 수 없습니다.자바에서는 계층이 존재하며, 이를 통해 상속이 가능합니다. 또한, 객체는 객체를 멤버필드로 가질 수 있습니다. 즉 객체의 참조값 다시말해 객체의 주소값을 가지고 객체에 접근 할 수 있습니다.그리고 데이터베이스에서 연관 관계일 때는 FK(외래키)를 사용할 뿐, 계..

Optional를 왜 사용해야 하는지 정리해보자! public final class Optional { ... } 공식 문서 API Note Optional is primarily intended for use as a method return type where there is a clear need to represent "no result," and where using null is likely to cause errors. A variable whose type is Optional should never itself be null; it should always point to an Optional instance. 옵셔널은 주로 메소드의 리턴 타입으로 사용하기위해 의도된거야근데 어느 메소드냐..

Controller - Service - Repository 중 예외를 어디서 처리해야할까? “나만(너희들은 안 하는) 할 수 있는 일은 내가 하고, 네가(자주) 하는 일이면 내가 넘겨줄게!” 하나의 계층에서 예외 처리를 모두 담당하지 않고, 모든 계층이 역할을 분담한다. 예외 발생 시 어느 한 계층에서 예외를 모두 처리하는게 아니라, 해당 계층의 역할과 관련되거나 그 계층에서만 하는 예외에 대한 처리라면 일부 처리를 해준 후에 예외를 상위 계층으로 던지다. 그리고 상위 계층은 이러한 예외 처리를 받아 예외 처리에 대해서 공통적으로 처리하면 되지 않을까?! Service에서 예외를 모두 처리하게 될 때, HTTP Status Code를 응답으로 전해줘야할 경우를 생각하여 Controller에서 예외를 모..

원숭이 엉덩이는 빨개, 빨가면 사과, 사과는 맛있어 우리는 익숙하게 사물과 사물을 연관지어서 생각할 수 있어, 관계형 데이터베이스(RDBMS)를 자연스럽게 받아들인다. 마치 객체지향을 공부할 때, 우리가 사는 세계와 비유하는 것을 자연스럽게 받아들이는 것처럼 그럼 관계형 데이터베이스에서, 두 테이블의 관계가 다대다(M:N)일 때, 이것을 일대다(1:N), 다대일(M:1)로 만들어주는 이유가 뭘까? 자, 다대다(M:N)가 되는 상황부터 살펴보자! 우리는 각 게시글마다 댓글을 등록한 회원들을 알고싶다. 하나의 게시글에는 여러 명의 회원이 댓글을 등록할 수 있고, 한 명의 회원 또한 여러 개의 게시글에 댓글 등록이 가능하다. 이러한 관계는 다대다가 될 수 있다. 다대다의 관계로 테이블을 구성을 어떻게 하면 될..

DTO(Data Transfer Object)를 직역해보면, 데이터 전송(전달) 객체라는 뜻이다. 이미 만들어놓은 도메인 객체를 사용하면 될텐데, 왜 DTO라는 객체라는 개념을 만들어서 사용해야하는걸까?! 과연, Transfer 전달을 위해서만 필요한 객체일까?! 그럼 도메인 객체를 Controller - Service - Repository(스프링 3계층)에서 모두 사용했을 때의 장점과 단점부터 알아보자! 장점하나의 객체만 사용하면, 관리할 것도 하나이기 때문에 편하다. (개발자가) 단점Controller - Service - Repository(스프링 3계층) 간의 이동 시에 데이터가 변경될 수 있다. 낮은 데이터 신뢰성사용자에게 보여줄 필요 없는(시스템에서 필요한) 데이터가 포함되어 이동되고, 사용..