사진관련 게시판 구현.

상당히 일거리가 많고 생각해야 될 사항이 많다.

1. 사진의 저장위치.

2. DB에 전체경로를 저장할 것인지, 파일명만 저장할 것인지.

- 나는 파일명만 저장했다. 그리고 저장경로는 서블릿 파라미터로 프로퍼티파일에 저장된 경로를 불러왔다.

- 따로관리를 결정한 이유는 추후에 저장 폴더를 변경할때 서블릿 파라미터만 수정하면 되기 때문이다.

- 전체경로를 저장해버리면, 파일경로 수정에 상당히 고단픈 작업일것이다.

- 하지만, 이로인해 사진을 저장하고 불러오는 과정에서 저장경로를 어떻게 전달하고 결합시킬것인지가 문제가 된다.

3. 한번에 여러파일을 저장했을 때, 하나의 게시물 번호에 여러 파일이름이 저장된다.

- 즉, 파일이름관리 테이블에서는 더이상 게시물번호가 기본키가 될 수 없게된다.

- 게시물 번호가 중복되고 파일 이름이 전부 달라진다.

- 게시물 저장 후 확인을 위해서 게시물을 불러 올 때, 리스트를 보여주기위해서 하나의 사진만 불러올 때 등,

쿼리문이 복잡해지기 시작한다. group by절을 사용하거나 order by절을 중복사용하거나 해야되는 상황이 생긴다.

4. 테이블이 3개로 갈라지면서 서비스 클래스에서 처리해야될 코드양이 확 늘어났다.

- 위에서도 언급했지만, 게시물 정보테이블, 게시물의 text내용관리 테이블, 

파일이름관리 테이블(중복문제때문에 따로 관리해야되는 상황이다.)이 생성된다.

- DAO역할의 분담을 확실히 하고자(명확하게 하고자) DAO에서 하나의 메서트는 하나의 쿼리문, 

많아야 방금 입력한 게시물의 번호를 조회하거나, 조회시 count업데이트를 위해서 한번의 쿼리문을 추가한게 전부다.

- 서비스 영역에서 각각의 메서드를 불러와 결과를 처리하는 역할을 하게된다.

- 3개의 테이블이라는 뜻은, 처리해야될 쿼리문도 늘어난다는 뜻이고, DAO에서 정의되는 메서드도 늘어난다는 뜻이다.

이는 곧 서비스 영역에서의 코드양이 늘어나는 결과로 이어진다.

- 거기에 더해서 3개의 테이블에서 전달된 각각의 데이터를 조합하는 작업을 해야된다. 

이 또한 코드나 늘어나게 되는 원인이다.

- 하지만, 테이블이 갈라져 있는이상, 어디선가는 처리해야 될 코드들이다.

5. 각각의 메서드에서 각각의 다른 컬랙션타입의 데이터를 전달받는다. (list를 보여주기위한 부분)

- 각각의 테이블에서 넘어온 데이터는 서로의 짝을 맞추기위한 기준 키를 포함해야 하기에 컬랙션이나 프로퍼티를 사용해야 했다.

- 초기에 HashMap컬랙션을 사용했었는데, 이녀석은 순차적으로 데이터를 저장하지 않는다는 성질이 있었다.

(자꾸 결과가 뒤집어져 나오기에 찾아보다 알게됨) List계열의 데이터 타입이 아니다 보니 불규칙하게 저장된 데이터가 

Iterator로 Key를 뽑으려 하니, 결과가 뒤집혀서 출력을 하게 된다. (한참을 찾았다...;;;)

결국, 한쪽이 String, String데이터로 처리를 하는 프로퍼티로 해봤는데 일단 제대로 정렬되어 나온다.

그런데 이녀석(Properties)의 정체가 잘 확인이 안된다. LinkedHashMap이라는 자료형이 있는데 순서를 보장한다고 한다.

이녀석으로 다시 시도를 해봐야겠다.