프로젝트를 진행하며 - 4 -

비어있던 소계 dto에 값을 만들고, 아직 만들지 않은 합계 dto를 만들겠습니다.

원래 처음 쿼리에서 select해온 결과 list가 있지만

여기서는 resultDtoList라는 새로운 객체를 만들어서 view에서 뿌려주도록 하였습니다.

StatusTable의 createMenuTitle() 메서드가 그 역할을 합니다.

위의 메서드와 createSubSum(); 메서드를 거치게 되면 resultDtoList는 최종적으로

합계, (의류카테고리의 소계), 점퍼, 바지, 셔츠, 티셔츠, ... (가전 카테고리의 소계), TV, 냉장고, 김치냉장고, ... (스포츠 카테고리의 소계), 운동화

이런 순서를 갖게 됩니다. 합계와 소계는 자기에게 맞는 값들을 다 가지고 있는 상태가 되지요..

keySet으로 좌측 메뉴의 순서와 우측 값의 순서가 맞추어지기 때문에 view에서는 그냥 list의 loop를 돌면서 뿌리기만 하면 됩니다. 합계, 소계는 이미 순서대로 resultDtoList에 들어가 있기 때문에 view에서 if else를 통해 합계를 제일 위로 뿌리고 소계를 그 다음에 뿌리고 하는 등의 로직이 들어갈 필요가 전혀 없게 됩니다.

그런 일들은 이미 밑단에서 끝난 상태이기 때문이죠..


말도 어렵고 소스도 보기 힘들지만..(진짜 어렵네요 -_-) 결국 하고 싶었던 것은
데이터를 내가 쓰기 편한 상태로 바꾸고, 소계나 합계가 필요하면 그것은 꼭 쿼리에서 계산하지 않아도
얼마든지 계산 할 수 있고, 하나의 DTO를 잘 설계해서 유용하게 사용 할 수 있다는 점입니다.

이런 과정을 통하게 되면 view에서는 로직이 많이 제거되고
위 기본적인 table 클래스들을 상속받아서 사용하게 되면 좌측의 메뉴나 헤더등은 각각의 장표 테이블 메뉴에 맞춰서
메뉴 그리는 로직을 구현하면 될 것입니다.

기본적인 데이터의 구조는 StatusTable에서 이미 만들어서 resultDtoList에 만들어 놓은 상태니까요..



물론 그만큼 service나 domain이 복잡해지겠지만..

그런 것은 선택이 아닐까 싶기도 하구요.. 결국 view건 service건 어딘가에서는 해줘야 하는 작업이니까요..

 view에서 그냥 그리겠다 라고 한다면..

쿼리에서 소계, 합계 다 뽑아내고 view에서 loop 돌면서 그릴 수도 있을거구요.. 평균을 보여줘야 한다..라고 한다면

평균 구하는 쿼리 새로 만들어서 처리하면 되겠지요..

위와 같은 방식은 평균을 보여줘야 한다라고 하면 DTO가 값을 return할 때 현재 자기가 보여줘야 하는 것이 평균값인지

합계 값인지 flag 값을 가지고 그에 따라서 바꿔서 보여주기만 하면 됩니다.

 @RequiredSum
 private BigDecimal totalOrdAmtToday = BigDecimal.ZERO;
 
 public BigDecimal getTotalOrdAmtToday() {
  if(isReturnAvg()) { //평균값을 보여줘야 하면
    //dividorAvg는 몇으로 나누어줘야 하는가 인데.. 이것은 어디서든 구해서 DTO에 set해주면 된다.
    return totalOrdAmtToday.divide(dividorAvg,BigDecimal.ROUND_HALF_UP); //dividorAvg로 나눈 값을 보여준다.
  }
  return totalOrdAmtToday; //아니면 그냥 값. 이 값은 이 DTO가 합계를 나타내는 DTO면 총 합을 가지고 있을 것임.
 }

어느것이 더 편한지는 상황에 따라 다르겠지만요..

작성하기 전에는 스스로도 한번 정리를 해놓고 싶어서 잘 작성하고 싶었는데..

생각보다 글이 길어지게 되고..

이 긴 소스들을 포스트에 다 붙여 넣을 수도 없고..

이런저런 생략을 하게 되고, 말빨도 부족하고 하다보니... 용두사미가 되어버린 것 같습니다.

아무튼.. 생각의 전환을 한번 해보고 싶었습니다.

1. 왜 소계 합계는 꼭 쿼리에서 내야 할까..
2. 평균을 구하려면 쿼리를 하나 더 만들어야 할까.. 거의 같은 모양의 쿼리를..
3. 메뉴 순서를 바꾸려면 쿼리에 order by를 줘야 하나.. keySet의 순서를 comparator를 입맞에 맞게 구현하여 사용하면 쿼리보다 더 빠르게 정렬 시킬 수 있지 않을까..
4. 테이블도 하나의 클래스이고.. 각각의 row도 하나의 DTO 클래스로 볼 수 있지 않을까..

하는 정도의 생각의 전환을 해보고 싶었습니다..

같이 일하는분께 이렇게 만든 클래스를 주고 이걸 상속해서 사용해보시라고 했더니

일단 위와 비슷한 모양의 테이블에서는 쓰기 참 좋다고 하시더라구요.. 쿼리도 간단해지고..

물론 여러 다른 모양의 테이블에서 사용하기 위해서는 좀 더 연구를 해봐야겠지만요..

아무튼.. 좋은 경험이 된 것 같습니다.

그동안 풍대리님께 배웠던 내용을 한번 접목 시킬 수 있는 기회도 되었구요.. (나름대로의 접목이고..많이 미흡하지만..)

그리고 추과장님께는 이 모듈의 리팩토링을 부탁드렸습니다. 분명히 잘못된 곳이 있을 테니까 잘 잡아주셔서 더 탄탄한 모양새를

만들 수 있게 해주시리라 생각합니다..



일반적인 사용은 이렇습니다.