프로젝트91 [Dev] 23.02.03. 회원 탈퇴 기능 (with. modify delete query) 회원 탈퇴 기능을 마지막으로 기획했던 마이 페이지에서의 모든 기능은 구현이 완료된다. 하지만 기능에서 동작하는 query 에 대한 고민이 계속되는 중에 여러 게시글을 일괄적으로 삭제하는 기능에 대해 동작하는 query 에서도 다른 query가 동작했으면 하는 바람이 있었다. 회원 탈퇴 기능으로 인해 동작하는 query 또한 사실 거기에 사용자의 정보를 하나 더한 delete query가 동작하는 것만이 다르다. 따라서 회원 탈퇴 기능을 구현하면서 delete query가 다르게 동작하도록 수정하는 것이 이번 작업의 목표이다. 작업 회원 탈퇴 기능 구현 my-page.js document.querySelector("#exitBtn").addEventListener("click", function(e){ v.. 2023. 2. 3. [Dev] 23.01.29. 게시글 일괄 삭제 게시글을 삭제하는 기능은 사실 이미 구현되어 있다. 하지만 필자가 계획했던 것은 사용자의 마이 페이지에서 삭제하고 싶은 게시글을 일괄적으로 선택하여 삭제할 수 있도록 하는 기능도 있었다. 따라서 우선 해당 페이지를 먼저 구축해야 한다. 이후에 동작할 기능은 사실 동일한 것이기 때문이다. 게시글을 일괄적으로 삭제하는 기능에 대한 작업이지만, 사실 두 작업은 동일한 logic 으로 통일하게 될 것이다. 작업 menucheckbox.html 내 글 삭제하기 삭제 메뉴 이름 게시글을 일괄적으로 삭제하기 위한 template을 작성했다. 이는 기존에 게시글 목록을 불러오는 template에서 약간 수정된 것이다. my-page.css .stackBox{ position: relative; } .deleteBox{.. 2023. 1. 29. [Dev] 23.01.26. 게시글 목록 조회 시 참조 링크 조회하지 않기 현재 게시글의 List만을 불러오는 것에 참조 링크의 정보는 필요가 없는데, 불필요한 요청으로 인하여 select query가 동작하고 있어서 이를 수정해야 할 필요성을 느낀다. 이는 client로 data를 전달할 DTO로 변환하는 과정에서 무조건적으로 참조링크의 정보를 가져오도록 되어 있을텐데, 이를 단순히 목록만을 가져오는 것에 그친다면 select query 가 수행되는 것을 저지할 수 있다. 문제가 되는 부분은 Recipe Entity 의 DTO 로 변환하는 method에 있다. 단순히 게시글의 목록만을 return 하는 경우에도 이미지의 빨간 네모 부분이 동작하기 때문에 발생하는 문제다. 이를 분리해주면 되겠다. 작업 Recipe.java (...) public RecipeDto toDto().. 2023. 1. 26. [Dev] 23.01.26. JPQL을 활용한 게시글 data join select (feat. fetch join) 지난 게시글에서의 고찰 2 select 두 번 vs. join 한 번 Recipe 입장에서 Link와 Comment는 모든 정보를 필요로 한다지만 Recipe 입장에서 writer는 SpUser의 모든 정보를 필요로 하는 것이 아니다. 현 상황에서 Recipe 하나의 정보를 가져오는 것에 수행되는 query 문은 recipe table select 한 번, sp_user table select 한 번으로 총 두 번이다. 그런데 이를 아예 jpql을 사용해서 한 번의 select로 가져오는 건 어떨까? 두 번 select 하여 값을 DTO에 담아 response 하는 것이 아니라, query 문의 join을 활용하여 한 번에 조회한 뒤에 DTO에 담에 response 하는 방식이 더 좋은 방식이지 않을까?.. 2023. 1. 26. [Dev] 23.01.21. Service Layer에서 UserDetails 분리 지난 게시글에서의 고찰 1 Spring Security를 활용한 로그인 방식에 의존성이 생긴다? 사실 작업의 과정은 어렵지 않았고, 오래 걸리는 것도 아니었다. 하지만 바꾸고 보니 드는 생각이 있었다. 이런 식으로 로그인에 성공한 Principal 객체를 service logic에서 활용한다면, 이와 같은 로그인 방식을 사용하는 사이트에 한정되는 개발 방식이라는 생각이다. 이 상황에 만약 로그인 방식이 바뀌기라도 한다면? 그럼 활용했던 UserDetails 인 SpUser 객체와 관련된 모든 항목에 대한 수정 작업이 동반될 것이다. 그럼 로그인에 사용되는 UserDetails인 SpUser 외에, 따로 Member에 대한 Entity를 만들고 이를 table로 해야하는 것일까? 회원 가입 시에는 이 Me.. 2023. 1. 21. [Dev] 23.01.18. 게시글 작성 및 수정, 댓글 작성 (feat. Database Normalization(데이터베이스 정규화)) 국비 과정에서 필자가 작업했을 때도, 이번 작업에서도 필자는 동일하게 Database Normalization에 대한 생각을 하지 않고 있었다. Database Normalization (데이터베이스 정규화) 는 관계형 데이터베이스의 설계에서 중복을 최소화하도록 데이터를 구조화하는 과정이라고 하는데, 필자는 이에 대한 고민을 전혀 하고 있지 않았던 것이다. 고민을 하고 있지 않다는 사실을 지난 밤 지인에게 다른 항목에 대한 방향성을 의논하던 중에 알게 되었으며, 다른 것보다 이것이 중요하다고 판단되어 먼저 고찰을 하고 있다. 현 상황 지금 상황은 다음과 같다. 사용자의 data를 저장하는 table에서는 사용자의 닉네임 data를 저장하고 있다. 사용자가 작성한 게시글의 data를 저장하는 table에서.. 2023. 1. 18. 이전 1 2 3 4 5 6 7 ··· 16 다음
