국비교육도 그렇고 처음 입사했던 회사도 그렇고 전부 SQL을 직접 짜는 MyBatis를 이용했었다. JDBC를 사용하면서도 자바 백엔드 코드와 SQL이 함께 있는 로직도 경험하였을 때 백엔드 코드와 SQL이 분리된 MyBatis는 정말 편리한 프레임워크였다. 복잡한 SQL을 처리할 수 있고, 방금 insert한 데이터의 Key값을 받아오기도 잘 되어있고, 짜기 나름이겠지만 분리되어 있으니 유지보수도 나쁘지 않았다. JPA라는 기술을 첫 회사다닐 때 옆자리 개발자분 덕분에 어떤 기술인지 제대로 알게 되었는데 알게 된지 어언 2년 정도 지나서 한번 사용해보고 싶다는 생각이 들게 되었다. 무엇보다 마음에 들었던 것은 어떤 SQL 문법을 쓸지 신경쓰지 않아도 되는 것이었다. 나는 크로스 플랫폼, 하이브리드 같은..

어느 날 만들어놓은 로그인 기능을 살펴보니 줄이 그어져 있었다. authorizeRequests()의 deprecated.. 이걸 어떻게 대체하지? 라고 생각해서 찾아봤는데 생각보다..간단했다. 가운데에 Http만 넣어서 authorizeHttpRequests()라고 바꿔주면 된다. 그리고 antMatchers도 에러가 뜨는데 이클립스에서는 마우스만 올리면 알아서 대체 대안을 내어주었다. ant만 request로 바꿔주면 된다. 즉 정리하자면 authorizeRequests() -> authorizeHttpRequests() antMatchers() -> requestMatchers()

API를 이용한 서비스를 만들어야 할 때가 있다. 보통 API를 제공하는 측에서 API를 어떻게 사용할 수 있는지 문서를 제공하거나 그 가이드를 제공한다. www.API주소.com?파라미터1=값1&파라미터2=값2 www.APIAdress.com?parameter=value&key=value 이런 식이다 처음에는 이런 주소형식의 API를 사용하려면 자바스크립트 location.href 를 이용해서 주소를 넣고 값을 다루는 줄 알았다. 혹은 AJAX를 이용해서 주소를 보내고 리턴값을 받는? href 같은 주소 이동기술?은 오직 프론트에서만 다루는 줄 알았다. 국비교육을 들었을때도 프론트에서 처리하는 방법 밖에 안 배웠었던 이유도 있다. 그런데 이런 API를 다루는 로직을 생각하다보니 API의 value를 동..

프론트에서 백으로 데이터를 보낼 때 생산성을 이유로든, 너무 일회성이라 DTO를 만들기 애매할 때든, 어떤 이유가 되었던 간에 JAVA bean DTO를 만들지 않고 Map 맵 형식으로 키, 밸류를 받아 사용할 때가 있다. 그런데 Map형식으로 받은 데이터를 키값을 이용해 사용하려고 할 때 정수형 int를 선언해서 쓰려고 하면 에러가 발생한다. java.math.BigInteger cannot be cast to java.lang.Integer Map에서 정수를 꺼낼 때 BigInteger로 꺼내기 때문인데 추측하기로는 map에 들어오는 데이터가 long보다 큰 수일 수도 있으니 제한이 없는 BigInteger로 꺼내는 게 아닐까...추측해본다. 이 에러는 스프링에서는 두가지로 해결 할 수 있는데... ..

웹 기능을 구현하다 보면 서로 연관된 로직을 작성할 때 FK로 이어주기 위한 값이 자동으로 값이 할당되는 Auto Increasement(이하 AI) 값인 경우가 있다. 예를 들면 쇼핑몰에서 하나의 주문서 안의 여러개의 주문상품들. (주문서 번호가 13이라면 13의 주문서 번호를 가지고 있는 여러개의 주문상품들) 통장 개설할때 처음에 얼마를 넣으면서 통장을 만드는 등의? 하나의 백엔드 서비스 메서드 안에서 진행되는 것들이다. 그런데 이 AI값은 insert 되기 전에는 데이터 테이블 상에 없는 값이므로 가져오는 쿼리도 짜기가 막막하여 처음 로직을 수립할 때에 곤란을 겪을 수 있다. 이 AI 값을 가져오기 위해서는 여러가지 방법이 있겠지만 세가지 방법을 소개해보겠다. 세가지 중 두가지는 원시적인 방법이고 ..

1. 암호에 대한 기본 설명 스프링에서는 passwordEncoder로 DB에 비밀번호를 저장할때 관리자도 비밀번호를 알 수 없도록 비밀번호 암호화를 지원한다. 해시함수를 이용해서 암호화를 하게 되는데 암호화 된 비밀번호는 사람이 알아보기 어려운 형태를 띤다. 예를 들어 비밀번호가 1234 라면 암호화되었을때는 → '$2$17a$L3kE8oeG...' 암호학의 어떠한 수학 공식을 이용해서 사람이 알아보기 힘들게 저장 된다. 암호학에 관련된 영역까지는 모르니 넘어가고 이렇게 암호화 된 비밀번호와 내가 로그인 할때 입력한 비밀번호는 당연히 다를 수 밖에 없는데 어떻게 로그인이 되는 것일까? 아! 나는 바로 생각해낼 수 있었다. 옛날에 군대에서 파일을 암호화해서 송/수신하고 송수신 된 파일을 보기 위해서 복호..

처음에 스프링을 배울 때 Controller, DAO, DTO, Service 로만 배웠다. 이 중에 DTO에 관련된 부분에서 Entity나 VO라는 개념 없이 DTO로만 배워서 DTO로 다 하는 줄 알았는데 역시나 스프링의 세계는 심오하고도 깊었다. 논리적인 분리이지만 쉽게 얘기하면 DB에 Insert, update 할 때 쓰이는 Entity 사용자단에서 보이는 데이터를 뿌리는 용도의 DTO VO 불변이라지만 사실상 개념의 차이인듯 하다 Mybatis를 이용해서 두 테이블을 JOIN해서 resultType으로 두가지 DTO를 받고 싶을 때 resultMap을 이용하는 방법도 있지만 그때그때 페이지에 보여줄 DTO를 계속 만들어주는 것이 보안적으로도 좋고 쿼리를 짜기에도 좋고 훨씬 생산적이라고 생각한다.

음악 데이터테이블이 있고 컬럼 중에 장르가 있다고 가정한다. 각 장르는 숫자로 구분한다. 0 = 롹 1 = 힙합 2 = 발라드 3 = 트로트 음악(music) 노래 가수 장르 좋은 날 아이유 1 (힙합) Rocking tonight 메탈리카 2 (발라드) 불타오르네 방탄소년단 3 (트로트) 뚜두뚜두 블랙핑크 0 (롹) 우주를 줄게 볼빨간 사춘기 1 그건 아마 우리의 잘못은 아닐거야 백예린 2 좋니 윤종신 2 킬리만자로의 표범 조용필 3 서버에서 music이라는 이름으로 뷰단에 데이터가 넘어온다고 가정해보자 서버에서 뷰로 데이터를 뿌릴 때 서버사이드 렌더링이라면 표현언어를 사용하여 if문 속에 태그 내용을 써서 조건을 줄 수 있지만 타임리프 롹 힙합 발라드 트로트 JSTL 롹 힙합 발라드 트로트 태그별로 ..

class~~~cannot be cast to class ~~ Entity와 DTO 혹은 VO를 구분지어서 사용할 때 만날 수 있는 에러이다. 컨트롤러에서 Entity로 받고 Mybatis에서는 DTO로 resultType을 받는 경우이다 나의 경우 둘을 맞춰주었더니 해결되었다.. 무슨 Devtools를 지우고 진행해라 이런 글도 있었는데 개발환경 상 불가능했기에 나의 실수가 있는지 찾아보다가 발견하였다.

예전에 했던 프로젝트를 리팩토링해보면서 스프링의 DAO와 DAOImpl, Service의 상관관계를 생각해보게 되었다. sqlsession 때문에 DAOImpl을 만들지만 왠지 모르게 이 로직을 머리로 생각을 했을 때 괜히 복잡해지는 느낌이 있었다. 그런데 무려 인터페이스에 @Mapper만 달아주면 Impl이 필요 없는 것을 발견하게 되었다!! 원래라면 sqlsession을 이용해서 sql에 접근하지만 Mybatis 3.0부터 어노테이션만으로 매핑 사용이 가능하다고 한다!!

Validator 인터페이스를 구현하는 식으로 Validation을 해주려고 한다. 스프링에서는 Validator 인터페이스를 지원하여 어플리케이션에서 사용하는 객체를 검증할 수 있는 기능을 제공한다. validation 이란 유효성을 검증하는 것으로 예를 들면 회원가입을 할 때 아이디가 너무 짧으면 몇 글자 이상으로 만들어야 한다고 알려준다거나 중복되는 아이디가 있으면 이미 사용되고 있는 아이디라고 알려준다거나 데이터가 정해진 기준을 충족하는지 검사를 하는 기능이라고 보면 된다. 시행하는 서비스 별로 Validator를 구분해서 만드려고 하는데 Validator가 많아질 수록 한눈에 보기도 불편하고 컨트롤러마다 이름을 수정을 해줘야하는 것이 번거로웠다. 한 Validator 안에 서비스 구분없이 넣자니..

, & 등의 특수문자를 사용할 때 문자열과 태그를 구분해주기 위함이다. MyBatis를 사용할 때 부등호 같은 내용을 처리할 때가 있다 SELECT wr_uid uid, wr_subject subject, wr_content content, wr_name name, wr_viewcnt viewcnt, wr_regdate regDate FROM test_write Where viewcnt > 100 ORDER BY wr_uid DESC LIMIT #{from}, #{pageRows} 위 쿼리의 경우 기본적인 게시판을 구성하는 DB가 있고 데이터 중 wr_viewcnt(조회수)가 100이 넘는 쿼리를 불러오고 싶다. 그런데? 오류가 나버린다. 위의 태그와 조회수 검색 조건인 부등호 >를 컴퓨터가 ..