[BackEnd][Maven-PJ] 사내 개발자 커뮤니티 서비스 - 게시판 만들기 : 목록 조회

 

🧑🏻‍💻 Git Hub 주소

 

 

🗂 목차

● [BackEnd][Maven-PJ] 개발자 커뮤니티 서비스 - 게시판 만들기 : 글 등록(작성) / 수정

● [BackEnd][Maven-PJ] 개발자 커뮤니티 서비스 - 게시판 만들기 : 목록 조회

● [BackEnd][Maven-PJ]개발자 커뮤니티 서비스 - 게시판 만들기 : 상세 조회

● [BackEnd][Maven-PJ]개발자 커뮤니티 서비스 - 게시판 만들기 : 삭제

● [BackEnd][Maven-PJ] 사내 개발자 커뮤니티 서비스 - 게시판 : 답변 등록 / 수정

● [BackEnd][Maven-PJ] 사내 개발자 커뮤니티 서비스 - 게시판 : 답변 삭제

 

👨‍👩‍👧‍👦 회원 관련

● [BackEnd][Maven-PJ] 사내 개발자 커뮤니티 서비스 - 회원 관련 : 회원 가입

 

 

📚부 록 

● [BackEnd][Maven-PJ]개발자 커뮤니티 서비스 - 게시판 만들기 : Paging처리

 

🤔 내가 만난 Exception

● [Exception 정리] org.apache.ibatis.binding.BindingException: Invalid bound statement (not found)

● [Vue.js][Spring] Post Data 전송 간 null값 전송 문제

​

 

 

 

 

🚀 개발 관련 Q&A 게시판 서비스 - 목록 조회

 

 

    🔽  DevInquryController.java

 

최초 목록 조회라는 비즈니스 로직 처리를 위해 169번째 줄에서 Service에 해당 Method를 호출하는 것이에요. 나중에 수정되어야 할 부분이지만, 현재는 매개변수로 VO를 넣어주고 있는데, 차 후 목록 처리에 필요한 Paging 관련 매개 변수만 넣어주도록 바꿀 것이에요.

그런뒤 172번째 줄을 보면 조회수 Count를 하기 위해 Service에 해당 Method를 호출하고 있는 것이에요. 이 역시 VO를 매개 변수로 넣어주고 있답니다.

그런 뒤 175번째 줄에서 조회된 목록 Data를 HashMap에 넣은 뒤 List로 감싸 받은 다음 다시 result라는 HashMap에 넣어주는 것이에요. 176은 조회수에 대한 정보를 넣어준 뒤 반환하고 있는데, 조회수는 정수 Type으로 받아 전달하는 것이에요.

이렇게 결과값을 모두 HashMap result에 넣어준 뒤 응답 해 주는 것이에요.

 

 

 

    🔽  DevInquryService.java

 

Interface를 구현한 Impl에서 비즈니스 로직을 처리할 것이에요. 이 부분은 목록 조회를 처리하기 위한 추상 Method이고,

 

 

이 추상 Method는 조회수 Count를 위한 Method인 것이에요.

 

    🔽  DevInquryServiceImpl.java

 

해당 비즈니스 로직에서 딱히 해줄 것이 없기 때문에 바로 SQL 처리를 하는 Mapper에 해당 Method를 호출하고, 그 결과값을 바로 반환 해 주는 것이에요.

 

 

 

    🔽  DevInquryMapper.java

 

 

그럼 이제 해당 Interface를 구현한 Mapper XML을 만나러 가볼 것이에요.

 

    <!-- Q&A 목록 조회 -->
    <select id="devInquryList" parameterType="com.devcommunity.junyharang.model.vo.support.DevInquryVO" resultType="com.devcommunity.junyharang.model.vo.support.DevInquryVO">
        select row_number() over(order by i.INQRY_SN asc) as INQRY_INDEX , i.INQRY_SN, i.INQRY_USER_SN , i.FILE_SN , i.INQRY_CN , i.INQRY_SJ , i.SECRET_AT , i.ANSWER_AT , i.ANSWER_CN , i.ANSWER_USER_SN , i.ANSWER_DT , i.CREAT_DT , i.UPDT_DT , i.UPDUSR_SN, u.USER_ID
        from tb_com_inqry i inner join tb_user u
        on i.INQRY_USER_SN = u.user_sn
        where 1=1
        <if test=' srchType neq null and srchType neq "" '>
            <choose>
                <when test="srchType eq '1'.toString()">
                    and INQRY_SJ like CONCAT('%', #{srchWord}, '%')
                </when>
                <when test="srchType eq '2'.toString()">
                    and INQRY_CN like CONCAT('%', #{srchWord}, '%')
                </when>
                <when test="srchType eq '3'.toString()">
                    and u.USER_ID like CONCAT('%', #{srchWord}, '%')
                </when>
            </choose>
        </if>
        order by INQRY_SN desc
        <if test=' pageStart neq null and perPageNum neq null '>
            LIMIT #{pageStart}, #{perPageNum}
        </if>
    </select>

 

위에 SQL문 중 

select row_number() over(order by i.INQRY_SN asc) as INQRY_INDEX

 

이 부분은 바로 조회할 때 순서 번호를 매기기 위해 사용하는 것이에요.
ROW_NUMBER 함수를 사용할 때는 ORDER BY를 필수로 사용해야 하는데, 딱히 정렬할 것이 없으면 

select row_number() over(order by (SELECT 1)) as INQRY_INDEX

반응형

 

이렇게도 사용할 수 있는 것이에요. 하지만, 주니하랑은 해당 게시판 게시글의 일련번호(고유 번호)인 ID값을 오름차순으로 정렬하여 순번을 매기는데, 해당 컬럼 별명을 INQRY_INDEX로 하여 조회 해 달라고 처리 한 것이에요.

 

그리고, 회원 정보를 가져와서 누가 작성했는지, 누가 수정 했는지에 대한 처리를 해주어야 하기 때문에 inner join으로 회원 Table을 Join 시켜 줬고, 해당 게시판 Table의 회원 일련번호와 회원 Table의 회원 일련번호를 On 조건으로 Mapping하여 조회 하려고 한 것이에요.

40번째 줄을 보면

<if test=' srchType neq null and srchType neq "" '>

 가 있는데, 해당 내용은 만약 srchType(검색 Type)이라는 값이 Null이 아니고, srchType이 비어있지 않다면? 이라는 조건절을 준 것이에요.

그리고, 여러 조건절을 주기 위해 <choose> 와 <when>을 사용하여서 srchType이 1이라면 and 조건으로 INQRY_SJ(게시글 제목) 가운데에 srcWord(검색명)과 같은 것이 있는지 찾도록 한 것이에요. 참고로 CONCAT 함수는 여러 범위 또는 문자열 Text를 결합하려고 사용하는 것이에요.

CONCAT 뒤에 의미는 '%'(모든 문자열) 과 #{srchWord} (검색명) 그리고, '%'(모든 문자열)을 하나로 합친 문자열이 INQRY_SJ(게시글 제목과 같은지를 묻고 있는 것이에요.

이 Logic은 게시글 검색을 위해서 만들어 진 것이에요.

 

마찬가지로 45번째 줄에는 검색 타입이 2라면 INQRY_CN 즉, 내용에 검색명이 있는지를 비교하는 것이고, 마지막 검색 타입이 3이라면 회원의 ID값을 검색하는 것이에요.

조건절이 끝나고 나면 게시글 일련번호를 내림차순으로 정렬을 하고, Paging 처리를 위한 조건절이 시작 되는 것이에요.

54번째 줄에 요청으로 들어온 VO Member 변수 중 pageStart(페이지 시작번호)가 Null이 아니고, perPageNum(Page 당 보여줄 게시글 개수로 설정)이 Null이 아니라면? 조건절 안으로 들어가서 LIMIT를 통해 Paging 처리를 하여 pageSta(0부터 시작) 에 들어온 숫자 부터 perPageNum개 까지 Data를 추출하도록 한 것이에요.

 

 

 

이 친구는 조회수를 카운트하기 위한 SQL 문인 것이에요. COUNT() 함수 안에 *을 넣어 tb_com_inqry Table의 모든 컬럼들에 대해 개수를 세겠다는 것이고, 그 결과를 COUNT라는 별명으로 컬럼에 만들어 달라고 한 것이에요.
사실 이 Logic은 Count만 하면 되기 때문에 아래 SQL문은 필요가 없을 것으로 생각되지만, 이 부분은 나중에 Refactoring 하도록 할 것이에요.

 

 

 

 

 

📣 결과

 

그럼 검색을 할 건 아니닌까 srch에 대한 내용은 대충 적고, Page 시작점과 개수를 적어서 요청을 보내면 다음과 같이 목록 조회를 성공하는 것을 볼 수 있는 것이에요.