DB에 연결해서 데이터를 가져오는 것에 아무 생각 없이 @Repository 어노테이션을 붙여서 개발을 하고 있었다. 그러던 중 지인이 @Mapper와 @Repository의 차이에 물어왔고 생각해보니 그 둘의 차이점을 몰라 구글링을 해보다보니 두 어노테이션은 크게 차이가 없지만 Repository와 Mapper 간에는 차이가 있다는 것을 알고 정리를 해보려한다. 애초에 구글링해서 나오는 글들은 javadoc을 그대로 번역하거나 뭔가 내 기준으로 와닿지 않아서 내 말로 정리하는게 필요할 것 같다. Mapper란 우선 repository와 Mapper를 비교할 때 mapper가 작은 단위이다. 밑에서도 설명할테지만 repository는 mapper를 포함하고 있다. mapper는 00.xml과 같이 sql..
지금까지 개발을 하면서 테스트 코드 짜는 것을 같이 병행하지 않았지만 최근 들어 테스트 코드를 작성하는 버릇을 들이기 시작했다. 그 중 메소드 분리 및 알맞은 접근제어자를 사용하기 위해서는 단위 테스트가 중요한데, 이 단위 테스트를 하다보면 당연히 해당 로직과는 상관없는 DI 되는 다른 객체들의 로직을 무시하기 위해 Mockito를 사용하게 된다. static 함수 처리의 경우 PowerMokito 또는 MockedStatic을 이용하는 방법 이렇게 두 가지가 있는데 여기서는 MockedStatic을 이용하는 방법에 대해 정리해보겠다. mockito core, inline dependency MockedStatic은 mockito 안에 있는 클래스이다. 스프링부트 프로젝트(모듈)을 생성하면 기본으로 sp..
빌더 패턴(Builder pattern)이란? 객체를 정의하고 그 객체를 생성할 때 보통 생성자를 통해 생성하는 것을 생각한다. Bag bag = new Bag("name", 1000, "memo"); 하지만 생성자를 통해 객체를 생성하는데 몇 가지 단점이 있어 객체를 생성하는 별도 builder를 두는 방법이 있다. 이를 빌더 패턴이라고 한다. Bag bag = Bag.builder() .name("name") .money(1000) .memo("memo") .build(); 객체를 생성할 수 있는 빌더를 builder() 함수를 통해 얻고 거기에 셋팅하고자 하는 값을 셋팅하고 마지막에 build()를 통해 빌더를 작동 시켜 객체를 생성한다. 빌더를 써야하는 이유 객체를 생성하는 방법이 생성자말고 빌더..
예전에 커스텀 어노테이션을 만드는 방법에 대해 글을 정리했었다. https://pamyferret.tistory.com/47 custom annotation(커스텀 어노테이션) 만들기 개발을 하다보면 AOP 적용을 위해서 별도로 커스텀 어노테이션을 만들어야할 일이 생긴다. 물론 AOP 적용을 패턴을 통해 적용시킬 수 있지만 같은 공통 기능을 사용해야하는 메소드들에 공통점이 pamyferret.tistory.com 그 때 만들었던 커스텀 어노테이션은 단순히 속성 값을 하나만 받는 어노테이션이었다. 하지만 만일 하나의 속성에 대해 값을 여러 개 받아야하는 경우 어떻게 해야할까? 그럴 때는 해당 속성의 타입을 배열로 지정하면 간단하게 끝날 일이다. 참고로 List와 같은 컬렉션은 어노테이션의 멤버로 설정이 불..
작년에 처음 IntelliJ IDEA를 사용하기 시작하면서 이클립스와는 다른 단축키들을 익혔었다. 그 중 하나가 Gradle Project를 Gradle로 빌드 할건지 IntelliJ IDEA로 빌드할 것이지 설정이었다. 처음에는 기본 설정인 Gradle 빌드로 사용하다가 IntelliJ IDEA가 빠르다는 지인의 추천을 듣고 IntelliJ IDEA로 바꿔서 사용했다. (참고로 이 설정은 IntelliJ Preferences(mac 단축키: command + ,) > Build, Execution, Deployment > Build Tools > Gradle에서 확인할 수 있다.) 잘 사용하던 중 Deprecated 처리 객체들을 정리하고 프로젝트를 실행시키니 갑자기 전에 지웠던 객체에서 내가 방금 지..
* 이 내용은 이펙티브 자바 12장 아이템 90의 내용을 토대로 작성되었다. 직렬화의 위험성 기본적으로 객체를 직렬화 한다면 implements Serializable을 많이 사용한다. implements Serializable을 사용해 자동으로 객체는 바이트 스트림으로 직렬화 하고 그것을 역직렬화 하는데 이 때 공격자는 바이트 스트림을 수정해 객체에서 외부에서 접근 불가하게 private으로 선언된 값을 참조할 수 있으며 수정해 불변식을 깨뜨릴 수 있다. 예를 들어 아래와 같이 기간을 저장하는 Period라는 클래스가 있다고 하자. public class Period implements Serializable { private final Date start; private final Date end; ..
개발을 하다보면 null 값 때문에 이런저런 오류들을 마주한다. 당연히 null 값이 아닐거라고 생각해서 사용하지만 객체의 경우는 기본적으로 nullable 하므로 얼마든지 null 일 수 있다. 만일 아래와 같이 특정 함수에서 list 객체를 반환받고 해당 객체에서 첫 번째 요소를 꺼내서 활용할 때 반환 받은 값이 null일 경우 에러가 발생한다. 이는 함수를 호출하는 곳에서는 null 값이 아닌 객체를 넘겨 줄 것이라고 생각하기 때문이다. public void test() { List list = subFunction(); System.out.println(list.get(0)); } 물론 애초에 객체를 반환하는 곳 내부에서 null 값이 아닌 빈 객체를 반환하도록 처리하거나 함수를 호출하는 곳에서 ..
- Total
- Today
- Yesterday
- JPA
- 어노테이션
- 역직렬화
- k8s
- 스프링부트
- ssh
- 데이터베이스
- DATABASE
- springboot
- 공간데이터
- 캐시
- Caching
- 자바
- 이클립스
- mockito
- MAC
- eclipse
- Java
- DB
- rabbitmq
- 캐싱
- Spring
- HttpClient
- enum
- postgres
- Intellij
- annotation
- cache
- 메시지큐
- PostgreSQL
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |