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

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

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