기록하는 프로그래머

필자도 한때 프로젝트를 뛰면서 생각없이 기간내에 처리하기 위해 @Autowired 를 이용한 의존주입을 남발하여 사용해왔고, 지금도 자연스럽게 이를 사용해왔습니다. (사실 Spring을 처음 접할 때 그렇게 쓰라고 가르쳤었음...) 생성자를 이용하는 것이 이점이 있음을 알고 있었지만 간편함에 빠진 오래된 버릇을 고치기란 쉽지 않았습니다. 그래서 신규로 하는 프로젝트에는 이런것들을 없애고자 @Autowired 를 완전 지양하도록 하려고 합니다. 이미 @Autowired 의 사용은 공식문서 그리고 Spring팀에서 지양을 권고해왔습니다. 단점들이 너무 명확했기에... - 불확실한 참조 - 코드 변이의 가능성 - 순환참조의 가능성 (컴파일 시 검출 불가) - 단일책임의 원칙 위반 가능성 장점은 남발하기 편하다..

리플렉션(Reflection) 을 사용하면 런타임 시점에 해당 클래스의 내부를 들여다 볼 수 있다. 클래스의 내부를 들여다 볼 수 있는 보안상의 이유로 코드작성을 지양하고는 있지만... 동적인 필드를 처리해야 하는 상황에서는 쉽게 접근 할 수 있는 방법이기도 하다. 사용자단에서 동적 key 를 가지는 Object 를 받아 엔티티 값을 set 해야 하는 상황이 생겨 여러 방법이 떠올랐으나 심플하게 적은코드로 처리 할까 하다가 리플렉션으로 처리하기로 했다. 데이터는 아래와 같이 동적 Object 형태로 만들어져 넘어왔다.

Optional 클래스를 사용하면 null 처리를 쉽고 가독성 좋게 표현해줄 수 있습니다. 그 중 JPA에서 자주 사용하는 엔티티 ID 값으로 조회하는 findById 는 Optional 로 리턴하는 메소드 중 하나인데요. Optional findById(ID id); 이렇게 id 값에 따른 엔티티를 조회하여 엔티티가 존재하지 않을 경우 대체처리하는 로직을 간결하게 수행할 수 있습니다. 저도 연관된 id 값을 반복 돌리면서 update를 수행하는 코드가 있었는데 생각없이 조건문과 isPresent() 를 이용해서 코드를 작성해놓고 보니 if != null 처리와 뭐가 다른가 싶은 생각이 들었습니다. param.getFileList().forEach(file -> { Optional loadEntityOp..

설정파일에 DB 정보와 Mail 발신인 정보가 그대로 노출될 경우 보안에 취약해질 수 있어 해당 정보를 암호화해서 넣어주거나 설정파일을 외부에 빼서 따로 관리해줘야 한다. Spring에는 Jasypt 라는 라이브러리로 암호화 시켜서 설정파일을 관리할 수 있다. Jasypt 라이브러리 등록 implementation 'com.github.ulisesbocchio:jasypt-spring-boot-starter:3.0.5' 암호화 방식 및 키값을 설정하는 빈을 생성. @Configuration public class ApplicationConfig { @Bean(name="jasyptStringEncryptor") public StringEncryptor stringEncryptor() { String ke..

Spring Security를 사용하면 강력한 로그인 기능을 사용할 수 있는데 간혹 내부 관련 각 사이트들끼리 자동 로그인을 시킬때가 있다. 이때 보통 A사이트에 로그인한 id 값, 쿠키, 세션 정보등을 가지고 B사이트에 넘겨주어 계정 정보를 조회하여 별도의 로그인 없이 처리해주는 기능을 만들 수 있다. 간단하게 A 사이트에서 로그인 한 뒤 id값을 전달하여 B사이트에서 id 체크 후 로그인 처리를 바로 해버리는 컨트롤러를 하나 작성하면 된다. @GetMapping("/loginWithoutForm/{id}") public String loginWithoutform(@PathVariable(value="id") String id) { UserDetails user = loginService.loadUse..

DB쪽을 엄청 빠삭하게 아는건 아니지만 JPA 사용하다가 DB 마다의 구조적 차이점이 꽤 영향을 주는걸 알게 되면서 간단하게 남겨본다. 보통은 데이터베이스 - 스키마 - 테이블 구조로 되어있고 데이터베이스 설정을 하고 엔티티에서 테이블 이름만 지정해놓고 사용하면 기본 디폴트 스키마를 기준으로 테이블 조회를 하게 되는데 다른 데이터베이스나 스키마를 다중 참조해야 할 때, 이 부분이 DB마다의 계층구조로 약간 상이해지는걸 발견했다. 모든 DB의 구조를 잘 안다면 큰 문제가 없었겠지만, 몇가지 DB만 쭉 사용하다가 어쩌다가 다른 DB를 쓸때 동일하게 설정했는데 table이 없다는 오류를 보고서 왜!!! 를 시전한것 같다. 보통 oracle 은 하나의 인스턴스에 계정별 스키마로 접근하게 되어있어 @Entity ..