코딩 잘하고 싶어

이전에 진행했던 프로젝트에서 JWT 로그인을 구현하였습니다. JWT 로그인에는 Access-Token과 Refresh-Token이 쓰입니다. 한마디로 표현하면, 액세스 토큰은 인증을 위한 토큰, 리프레시 토큰은 액세스 토큰을 재발급하기위한 토큰입니다. 리프레시 토큰은 서버에서 만들어서 MySQL에 저장하고, http 쿠키로 생성하여 프론트엔드로 넘겨주었습니다. 그런데 프로젝트 리팩토링을 진행하면서, MySQL에 저장했던 리프레시 토큰을 Redis로 바꾸려고 합니다.!! 왜 Redis로 바꾸는 것이 좋을 지에 대해 정리해보겠습니다. Redis 란? Redis(Remote Dictionary Server)는 [키(Key) - 값(Value)] 쌍의 해시 맵과 같은 구조를 가진 비관계형(NoSQL) 데이터베이..

요즘 프로젝트 리팩토링을 하면서, DTO에 작성하는 여러개의 lombok 어노테이션의 사용 이유를 정확히 알지 못하고 사용하는 것 같아서 하나하나 고찰(?) 해보기로 했다. 일단, DTO는 Data Transfer Object로, REST API 작성 시에 엔티티 대신에 DTO를 사용하여 컨트롤러에서 데이터를 주고받는 용도로 사용한다. DTO를 사용하면 엔티티에 변질을 막을 수 있고, 로직에 맞춰 필요한 필드만 주고받을 수 있어 DTO를 사용하는 것이 좋다. 컨트롤러에서 DTO를 주고받기 때문에 JSON 직렬화와 역직렬화가 일어난다. - 직렬화(serialization) : Java Object 가 JSON으로 변환되는 것으로, ResponseBody를 사용할 때 일어난다. (서버 -> 클라이언트) - ..

예전 프로젝트 리팩토링을 진행하다가 문득 궁금한 것들이 생겼다. JPA를 사용하면서 Entity, DTO 클래스에 꼭 여러가지 lombok 어노테이션을 달아왔었다. 예를 들어, @Builder, @NoArgsConstructor, @AllArgsConstructor, @Getter 등... 그런데 어느 순간부터 이 어노테이션이 왜 필요한지 어떻게 쓰이는지를 잊고 습관적으로 갖다 붙이고 있는 것 같았다. 알아도 정확히 알고 있는 듯한 느낌이 아니었다. 그래서 이에 대해 많이 검색해보고 알아보았다. 일단 Entity 클래스에는 @Entity 를 붙여야한다. 난 항상 이렇게 달아왔다. @Entity @Builder @AllArgsConstructor @NoArgsConstructor(access = Acces..

예외처리 프로그래밍을 할 땐 다양한 예외 상황이 발생한다. 이 예외 처리를 잘해야 좋은 프로그램이 될 수 있다. 예외 처리를 try-catch문을 사용하거나 다른 여러가지 방법들로 할수도 있지만, 이는 코드가 복잡해지고 유지보수 하기에도 어렵다는 문제점이 있다. 예외처리를 한번에 다른곳에서 처리하고 비즈니스 로직에서는 비즈니스 로직만 작성하여 코드가 복잡해지지 않도록 할 수 있다. @ExceptionHandler 이 어노테이션은 메서드에 붙일 수 있는데, @Controller와 @RestController가 적용된 Bean에서 생기는 예외를 캐치하여 이 메서드에서 처리해주도록 한다. 메서드의 인자로 캐치하려는 예외 클래스를 작성하면 된다. 리턴 타입은 하고싶은대로 해도 된다. @ExceptionHandl..

어노테이션을 이용하여 컨트롤러를 구현하는 방식의 가장 큰 장점 1) 컨트롤러 타입에 제한이 없다 다른 컨트롤러를 구현하는 방식들은 정해진 인터페이스를 구현해야 되요. 하지만 어노테이션은어느 클래스든지 컨트롤러가 될 수 있다. 2) 한 개의 컨트롤러에 하나 이상의 URL이 매핑될 수 있다 어노테이션을 이용하면 URL 매핑을 컨트롤러 클래스 단위가 아니라, 메소드 단위로 할 수 있다.**** 때문에, 요청의 타입이 늘어나도, 컨트롤러 내의 메소드만 늘어난다. @Component component-scan을 선언에 의해 특정 패키지 안의 클래스들을 스캔하고, @Component Annotation이 있는 클래스에 대하여 bean 인스턴스를 생성한다. @Controller, @Service, @Repositor..

정적 파일 서비스 하기 WEB-INF 안의 내용들은 기본적으로 접근이 불가하다. 예를 들어 css나 js나 image 파일들은 접근이 불가하다. 그런데 jsp파일은 접근이 가능하다. 왜일까? dispatcher / web.xml 파일에 보면 dispatcher의 servlet-mapping의 url-pattern을 / 로 지정했었다. /* 로 지정하면 jsp파일 까지 접근 불가능하도록 막는 것이고, / 로 지정하면 jsp파일만 요청에 대한 컨트롤러를 찾는다는 뜻이다. 그러니 css나 js, image 폴더의 파일들은 접근할 수 없다. 근데 그렇게 되면 js나 css 등 자원 파일들을 jsp에서 불러오지 못하는 문제점이 생긴다. 그래서 접근을 할 수 있도록 지정할 수 있다. [ dispatcher-serv..

서비스 객체 분리 service 객체에서 데이터베이스에 접근한다. 다만 직접적으로 service 객체를 가져다가 쓴다면, 결합력이 높아지고 이는 문제점을 일으킨다. 다른 종류의 service 객체를 사용할 때가 오면, 그때 그때 바꿔줘야하기 때문. 그래서 service interface를 만들고 그 아래에 여러 종류의 service를 만들어서 결합력을 낮출 수 있다. 아직 배우지않았지만 나중에 DAO라는 것으로 service 객체를 구분할 것이다.! 연결 정보 분리 service 객체 클래스마다 데이터베이스 연결 정보를 코드로 작성할 것이 아니라, xml 파일에 지정하여 한번에 관리하고 가져다가 쓰는 것이 바람직하겠다. 위와 같이 DataSource를 분리하고, 컨트롤러에서 dataSource.getCo..

페이지 모듈 분리하기 페이지마다 Header나 Footer와 같이 공통적으로 들어가는 요소들이 있다. 만약, Header의 코드를 고쳐야 한다면 모든 페이지의 Header를 일일이 고쳐야하는 불편함이 생긴다. 이러한 문제점을 막기 위해서 페이지의 공통 분모 집중화하는 것이 필요하다. 공통적으로 들어가는 코드들은 각각 jsp파일을 만들어 묶는다. 레이아웃 까지도 따로둔다. 😲 직접 예제 프로젝트의 페이지 모듈을 분리해보니 예전 웹프로그래밍 수업의 프로젝트가 생각났다. php 웹페이지였고, 막 웹에 대해 처음 배울 때였다. 그 때도 모든 페이지의 공통적으로 들어가 있는 코드들이 많았는데, 고칠때마다 모든 페이지의 코드를 고쳐야하니 매우 불편했다.. 사실 업무에서 이런 현상이 있다는건 말이 안되는 일이다..!..