SQL 쿼리를 JSP 에서 구현하는 이유

예전에 이렇게 코딩된 JSP 를 본 적이 있다.
DB 작업을 위한 Context, Connection, Statement, ResultSet 등이 JavaBeans 에 담긴 것이 아니라 JSP 에 존재하는 것이다.
물론 ResultSet 이야 JSP 에서 사용하려면 기술될 수도 있다.
그런데, ResultSet 의 맹점(?)이 몇가지 존재하기 때문에, 이것도 ArrayList 에 담기 쉽상이다.
그리고 이러한 코딩 방식을 폄하한 가장 큰 이유는, PreparedStatement 를 이용하지 않고 Statement 를 이용하였기 때문이다.
게다가 유사한 기능을 구현한 각각의 JSP 들에 처음부터 끝까지 DB 작업용 코드가 들어가 있지 않은가..!
비슷한 기능을 수정하려고 관련된 JSP 모두를 고쳐야 하니, 재사용성이 두드러지게 떨어지는 것을..
이렇게 그동안 폄하했던 프로그램 방식이 요즈음 구미를 당기고 있다, 물론 보완이 필요하지만..

Java 를 수정하였을때 웹서버의 설정에 따라 컨테이너가 자동으로 내려갔다 올라오기도 하고,
수동으로 내렸다 올릴 수도 있다. 그런데..
개발단계가 아닌 운영단계에서 이렇게 컨테이너가 오르내리게 되면 서비스에 문제가 발생한다.
예를들어 현재 물건을 구매 중인데, 운영중인 서비스가 내려갔다 올라가면 어떻게 될까..?
물론, 웹 서버도 여러대 있고, 어플리케이션 서버도 여럿 있어서 클러스터링이 되어 있으니 문제 없다고 대답할 수도 있다.
한쪽 컨테이너가 내려가도 이중 삼중으로 되어 있어서 서비스는 언제나 가능하다라고 믿을(?) 수도 있다.
그런데, 그렇지 않은 환경도 많다.
물론, 설정이 잘못되어 있어서 클러스터링 되어 있다지만 실제로는 문제가 있는 경우도 있다.
개발만 하지 말고 실제로 운영해 보시라.. 원인도 모를 데이타들이 쌓이는 이유를 가슴에 손을 얹고 생각해 보라.

자, 다시 본론으로 돌아가서..
운영중인 서비스의 경우 기존의 로직을 크게 흔들기 보다는 살짝살짝 수정하는 경우가 많다.
크게 흔들어야 하는 경우에는 아예 새로운 Java 와 JSP 를 만들기 마련이다.
그런데, 쿼리의 일부만 수정하면 되는 경우는 어떨까..?
JavaBeans 에 쿼리가 들어가 있다면, 이걸 컴파일 해서 .class 파일을 서버에 올리고..
자동이든 수동이든 컨테이너를 내렸다 올려야 한다.
그 과정에서 발생하는 미션 크리티컬한 장애를 누가 보상할 수 있을까..?
답은 쿼리를 JSP 에 담으라는 것. 왜냐하면 JSP 가 수정된다고 컨테이너가 내려갔다 올라오지는 않으니까.. ^^>

다만, 재사용 하기 위해 쿼리만 모아놓은 JSP 를 구현한다.
JSP 는 Java Package 구조에 맞게 디렉토리를 구성하고 네이밍도 이와같이 하면 된다.
물론, 쿼리는 Statement 를 사용하지 않고 PreparedStatement 를 이용한다.
아래 그림은 해당 내용을 구현한 JSP 사례다. 물론, 보안상 노란 색을 칠했다.

위에서 기술된 Info 에 아래와 같이 쿼리와 쿼리에 부속된 파라미터를 정의해 두어야 한다.
물론, 아래 내용과 다른 기본적인 내용을 하나의 Info 에 넣고 이것을 extends 해서 사용해도 된다.

DB 쪽 관리를 위한 기본 내용은 Java 에 담아서 활용하면 된다. 이것도 JSP 에서 구현하자고 하지는 말자.. ^^>
Java 는 Package 관리가 되지만 JSP 에서 구현된 넘들은 이것이 안되기 때문에 네이밍 룰을 운영하는데 아주 귀찮아진다.
예를들어, 하나의 JSP 에서 여러개의 JSP 를 정적 Include 한다고 해 보자. 프로그램 소스가 엉키는 것은 시간 문제일 뿐이다.