noobdev25 님의 블로그

이걸로 Board의 등록/조회/수정/삭제가 다 끝났다. 마지막인 삭제 얘기. CASCADE가 진짜로 동작하는지 확인 Comment, Files는 Board를 ON DELETE CASCADE로 참조하게 만들어뒀었다 (2주차 첫 글에서 다룬 내용). 게시글 하나를 지우면, 거기 달린 댓글/파일도 자동으로 같이 지워지는지 이번에 실제로 확인한 셈이다. Board만 지우는 코드를 짰는데도 DB가 알아서 정리해준다.// BoardMapper.xml DELETE FROM Board WHERE id = #{id}DELETE에 비밀번호를 어떻게 실어 보낼지 수정은 body로 값을 보냈는데, DELETE는 관례상 body를 잘 안 쓴다. 그래서 이번엔 쿼리 파라미터로 보내기로 했다. `DELETE /api/boar..

조회, 등록은 사실 데이터를 이 모양에서 저 모양으로 옮기는 것뿐이었다. 수정은 다르다 비밀번호가 맞는지 판단하는 로직이 들어갔다. 처음으로 진짜 "로직"이 생겼다 // BoardService.javapublic BoardResponse updateBoard(Long id, BoardUpdateRequest request) { BoardEntity board = boardMapper.selectBoardDetail(id); // 비밀번호 검증 if (!board.getPassword().equals(request.password())) { throw new IllegalArgumentException("비밀번호가 일치하지 않습니다."); } //바꿀 부분 덮어쓰기 ..

이번에는 목록 조회랑 상세 조회 두 개를 한 번에 만들었다. Category 때 이미 조회 패턴은 해봤으니 수월했다 목록/상세, SQL에서부터 다르게 짰다 목록 조회는 password를 아예 SELECT하지 않았다.// BoardMapper.xml SELECT id, category_id, title, writer, content, view_count, created_at, updated_at FROM Board ORDER BY id DESC 근데 상세 조회는 예외적으로 password를 포함시켰다.// BoardMapper.xml SELECT id, category_id, title, writer, content, password, view_count, created_at, upd..

자바 신입 백엔드 모의 면접 스터디 정리신입 자바 백엔드 개발자들이 모여 진행한 모의 면접 스터디 기록입니다. 각자 이력서 기반 질문과 CS 질문을 1~2개씩 준비해서 서로에게 면접관 역할로 질문을 던졌고, 스터디가 끝난 뒤 모범 답안을 함께 정리했습니다.이 글은 실제 면접에서 답변하듯 말하는 흐름 그대로 정리했습니다. 질문을 읽고 스스로 답해본 다음 아래 답변과 비교해보시면 더 도움이 될 것 같습니다.1. 운영체제Q. 프로세스와 스레드의 차이점과, 스레드를 사용하는 이유를 설명해주세요.프로세스는 운영체제로부터 독립된 메모리 영역, 그러니까 Code, Data, Stack, Heap을 각각 할당받는 실행 단위입니다. 그래서 프로세스끼리는 기본적으로 메모리를 공유하지 않습니다. 반면 스레드는 프로세스 내부..

지난 글에서는 Category 조회만 구현 했었는데 이번에는 Category처럼 조회만 하는 게 아니라,처음으로 쓰기(Create) 작업을 했다. 쓰기와 조회는 무엇이 다를까? Category는 조회만 있어서 Response DTO 하나로 끝났는데, Board는 등록/수정이 있어서 클라이언트가 보내는 값을 받을 Request DTO도 필요해졌다.public record BoardCreateRequest( Integer categoryId, String title, String writer, String password, String content) { }id, viewCount, createdAt처럼 클라이언트가 값을 정할 필요 없는 필드는 Request에 넣지 않았다.(이 값..

이번 글은 Category 조회 API 하나 완성하면서 배운 것들 정리해보았다코드보다는 개념 정리하는 데 시간을 더 많이 쓴거같다전체 흐름부터 정리 코드 짜기 전에 요청 하나가 어떻게 돌아가는지 순서부터 확실히 잡고 갔다.1. 클라이언트 → Controller (요청 도착)2. Controller → Service (서비스 메서드 호출)3. Service → Mapper (매퍼 메서드 호출)4. Mapper → DB (SQL 실행)5. DB → Mapper (결과 row들 반환)6. Mapper → Service (List 반환)7. Serv..

지난 글까지 목록 구현하면서 1주차(Servlet + JSP + JDBC) 분량은 일단 마무리됐다. 사실 완벽하게 구현해내지는 못했지만 이번 글은 1주차 끝내고 2주차(SpringBoot + MyBatis) 넘어가면서 세팅한 것들 정리해보겠다. 1. Git으로 이력 관리하는 법부터 다시 배움 사실 이번 스터디 하면서 제일 크게 배운 게 코드보다 이 부분이었음원래 나는 노션에 Todo 리스트 만들고 체크하는 식으로만 작업 관리를 했었는데, 이게 혼자 진행할 때는 상관 없지만 협업 방식으로는 별로 안 좋은 방향이라고 해서 GitHub Issue/Milestone을 사용해보려고 함 - Week2 마일스톤 만들고, 할 일을 전부 이슈로 쪼갬 (이슈 하나 = 단계적으로 끝낼수 있는 작업) - 이슈마다 브랜치 하나..

지난 글에서 write.jsp를 통해 데이터를 입력받고 DB에 적재하는 것을 구축했다.그럼 이제 그 글을 읽어보자. 아차차 우리는 아직 확인할수가 없다 그럼 어떻게해?그래서 이번에는 목록 조회를 구현해보고자 한다. 순서대로DAO에 데이터를 꺼내오는 기능을 추가 -> BoardListCommand 생성 -> 컨트롤러에 길 뚫어주기 -> list.jsp 만들기해보자 public ArrayList selectBoardList() { Connection conn = null; PreparedStatement pstmt = null; ArrayList list = new ArrayList(); //데이터를 담아올 바구니 ResultSet rs = null; //실행할 쿼리문 ..

이전 글에서 백엔드 파이프라인을 구축했다. 그러나 아직 사용자가 직접 상호작용할 수 있는 화면이 없다.jsp를 사용해서 직접 상호작용을 할 수있는 화면을 만들어보자 근데 JSP가 뭔데?일명 Jakarta Server Pages(Java Server Pages 에서 바뀐 이름이다 복잡한 사정이 있는거 같은데 중요한게 아니니까 넘어가자)HTML에 Java를 입힌 것이라고 생각하면 된다HTML(정적)은 누가 접속해도 똑같은 화면을 보여주지만, JSP(동적)는 서버에 있는 DB에서 데이터를 가져오기 때문에, 접속할때마다 새로 그려서 보내준다. 그러니까 간단하게 아래의 구조를 가진다고 생각하면 된다.브라우저가 jsp 요청 -> 서버가 jsp 파일을 받아서 자바 코드 실행 -> Java가 DB에서 데이터를 가져와 ..

지난 글에서는 백엔드 파이프라인이 완성 되었다. 그럼 이제 진짜 글 써도 됨?그러기에는 아직 치명적인 문제가 하나 발생한다. 클라이언트가 보내는 요청을 받아줄 진입점이 없다는것이다. 내가 만든 BoardWriteCommand는 일반적인 자바 클래스일뿐, 스스로 웹 URL 요청을 받거나 응답하는 능력이 없다클라이언트와 통신하려면 반드시 서블릿이 필요하다 그럼 어떻게 해야함?이 문제를 해결하기 위해 클라이언트의 요청을 하나의 서블릿이 다 받아서 조율하는 구조를 만들면 된다.이 서블릿이 URL을 분석해서 알맞은 Command 객체에게 처리를 넘겨주는 방식인 것이다. 그럼 이 역할을 수행할 서블릿을 만들자com.study.controller 패키지를 만들고 직관적으로 BoardController라고 이름 붙혔다..