스프링에 관한 잡다한 이야기
프로젝트 생성
이클립스에서 스프링 프로젝트 생성 시 다음과 같은 창이 뜬다.
옛날에는 (옛날이라 해도 1년도 안됐지만) 별생각 없이 만들어서 썼었는데 위에 보이는 Service URL은 대체 무엇일까..
이는 스프링 프로젝트 설정을 기본적으로 Service URL에서 가져온다는 뜻이다.
실제로 https://start.spring.io/ 홈페이지에 들어가 보면 스프링 프로젝트를 설정할 수 있다.
메이븐 프로젝트로 할지, 그래들 프로젝트로 할지 설정할 수 있고 Language와 Spring Boot 버전, Project 정보 등을 설정할 수 있다. (최근에는 그래들 프로젝트로 많이들 설정한다.)
아래에 Dependencies 오른쪽의 ADD ... 버튼을 클릭하여 Dependency도 추가할 수 있다.
Spring Boot 버전에는 여러 개가 있는데 이 중 SNAPSHOT이라고 써진 것은 아직 개발 중인 단계이고, M1은 미리 배포에서 개발자들이 미리 경험해보는 그런 단계이다.
Dependencies를 아무것도 설정하지 않고 GENERATE 하면 나중에 직접 pom.xml에 필요한 Dependcy를 추가해야 한다.
GENERATE 해서 생성된 압축 파일을 압축 해제하고, 해당 폴더를 이클립스 워크스페이스 폴더에 옮기고, File > Oepn Projects form File System를 클릭하여 압축 해제한 폴더를 불러오면 홈페이지에서 생성한 스프링 프로젝트를 사용할 수 있다.
스프링 부트(Spring Boot)
WelcomePageHandlerMapping.class에 index.html이 디폴트로 설정되어 있다.
따라서 static 폴더 내에 index.html을 작성하여 서버를 실행(ex. localhost:8080)하면 index.html 페이지가 기본으로 뜬다.
스프링 부트의 장점
1. 버전 명시를 하지 않아도 알아서 해준다.
2. start 부분에 기본적인 건 다 있기 때문에 의존성 추가 작업을 개발자가 덜 할 수 있다.
Dependency
스프링 프로젝트 진행 시 자바 파일을 수정할 때마다 서버를 재시작해줘야 변경사항이 적용된다.
Spring Boot DevTools Dependency를 추가하면 변경사항을 감지해서 자동으로 서버 재가동을 해주기 때문에 굉장히 편리하다.
JDBC, iBatis
일반 데이터베이스 JDBC와 스프링 JDBC가 있는데, 스프링 JDBC를 사용하는 게 편리하다.
예전에는 데이터베이스 종류(Oracle, MySQL, ...)에 따라 구현체를 개발자가 직접 구현했어야 했다.
이게 번거로우니 추상화를 해서 JDBC 인터페이스를 만들었다. 그래서 JDBC 추가만 하면 크게 신경 쓰지 않고 데이터베이스에 접근하기 쉬워졌다.
그런데 문제 아닌 문제 하나가 생기는데, 접속할 데이터베이스 드라이버와 계정, 비밀번호를 모두 명시해주어야 한다는 것이다. 이런 데이터베이스에 접속하기 위한 정보가 비즈니스 로직마다 다 들어가야 하니 interface에 담아서 비즈니스 로직 문제를 어느 정도 해결했다. 하지만 반복성 문제가 남아있었다..!
그래서 스프링에서는 이걸 또 추상화해서 properties 하나에 JDBC 환경 설정만 해놓으면 위와 같은 작업(데이터베이스 드라이버, 계정, 비밀번호 작성 등)을 하지 않아도 되게끔 했다. 이게 바로 스프링 JDBC이다.
여기까지는 스프링이 해결해줬는데.... 코드랑 SQL문이랑 결합되게 되어서..😭
conn.prepareStatment("insert into test values(?, ?);");위와 같이 SQL문이 코드에 들어가게 된다는 게 좀 그랬다.
개발자는 데이터베이스 쪽에 신경 쓰지 말고 정말 개발에만 신경 쓰고 싶었기 때문이다.
그래서 초창기에 iBatis가 나왔다. xml 파일에 따로 SQL문을 담아 결합도를 떨어뜨렸다.
이렇게 하면 물리적으로 코드와 SQL문이 떨어지긴 한다. 그러나 논리상으로는 떨어졌다고 말하기가 그랬다.
왜냐하면 MySQL이나 Oracle 등 데이터베이스마다 쓰이는 형식이 좀 다른 게 있었기 때문이다. (현재 시간을 표시하려고 할 때 MySQL은 now()를 쓰고, Oracle SQL은 sysdate를 쓰는 등)
결국 데이터베이스 종류에 따라 SQL문에도 영향을 끼치게 되어서 이것도 싫었다.
그래서 나온 게 JPA인데 쩝😫 성능 상으로 JPA가 좋다고 말할 수는 없다.
결론은 없지만 한 번쯤은 들어보면 재밌을 법 한 이야기
