Spring실습

24/12/19(목)⚡할 일: 1) 책 클래스2) 책 repository3) 책 service4) 책 controllerbook 클래스 만들기책 repository책 serviceservice에는 꼭 repository를 참조한다.책 controllercontroll

24/12/게시판게시글댓글🧐이게 바로 Entity 하나의 어플리케이션을 만들기 위해 필요로 하는 것들게시판게시판 이름게시글제목내용이름댓글내용나는 처음 만드는거기 때문에 많은 필드를 생각하지 않고, 작게만 시작한다.게시판 | 게시글 - 1:N하나의 게시판의 여러개의 게

24/12/23API spec?API 스펙은 프론트엔드와 백엔드가 주고받을 데이터의 값 이름, URL, 메세지 등을 공통적으로 설계하는 부분이다.❗Method, URL, Request, Response 4가지는 꼭 있어야한다.생성POSTPath/boardsRequest

24/12/24 게시판 만들기3 🔥1단계 게시판 조회 내가 만든 api 목록 조회 GET Path /boards Example Endpoint http://localhost:8080/boards Response

24/12/30(월)게시판과 게시글의 관계게시판과 게시글은 1:N관계이다.게시판이 없는 게시글은 없다. 따라서 게시글을 생성할때 게시판 id가 있어야만 만들 수 있다.<span style="background-color:- RequestResponse<spa

24/12/30(월)<span style="background-color:API을 보고, 그에 맞는 Request, Response를 작성해야한다.<span style="background-color:\`\`\`java@Entitypublic class Co

24/12/31(화)<나의 고민>❓ 조회수는 어디에 설치하면 될까?\-> 조회수는 게시글을 눌렀을 때 올라간다 : Post❓조회수를 count하는 함수도 필요하다.\-> 조회하는 부분을 눌렀을 때, count해주기만 하면 된다.post에서 관리하기 때문에 post

24/12/31(화)<나의고민>❓전체 게시판에서 검색 vs 특정 게시판 내에서 검색 전체 게시판에서 검색 : (그림을 그려서 생각) 네이버 카페에서 어떤 게시물을 어디서 찾는지 모르니까 전체 게시판을 통해 특정 단어로 찾는다고 생각/posts/search를 통해서

회원은 어떤 관계성이 있을까?post와 1:Ncomment 1:N생성Method : POSTPath : /users/infosExample Endpoint : 'https://localhost:8080/users/infos'Request : Request Bo

DTO설계API설계 가지고 controller 작성Repository 작성controller의 service함수 작성Entity작성Test 코드 작성하기😐 느낀점

validate 설정UserName은 최소 1과 최대 10 사이에 넣어주어야 한다.userName은 절대 빈칸이면 안된다.UserName(사용자 이름)최소 1과 최대 10 사이에 넣어주어야 한다.절대 빈칸이면 안된다.userInfoId(사용자 ID)최소 1과 최대 10

회원과 게시글의 관계한명의 회원이 여러개의 게시글을 올릴 수 있으니까 1:Npost가 N쪽이기 때문에 N쪽에 ManyToOne을 달아준다.그럼 post을 가져올 때마다 어떤 회원이 작성했는지를 반환해야한다.Request에는 userId가 있어야된다.그렇다면, post를

로그인은 post일까 Get일까?로그인은 사용자가 입력했을 때, 보내는거니까 post!loginRequest에는 뭐가 들어갈까?요청 줄 값은 로그인 정보인 아이디, 비밀번호를 준다.1) LoginRequest2) controller3) servicea) loginReq

24/12/26API 설계 (spec 정하기) \- 필요한 기능 \- HTTP method, (url)path \- 요청 시 데이터 / 응답 시 데이터개발 (백엔드) 1\. DTO 만들기 (가장 쉬움) 2\. 컨트롤러 (여기까지가 API sp

24/12/26(목)이렇게 만들고 싶음. title이 하나 있고, 그 안의 여러개의 content가 있는 상황DTO 만들기컨트롤러엔티티id, id뺀 생성자, 기본 생성자, getter리포지토리servicecrud는 같은 내용이니까 패스!일단 관계를 먼저 생각해보자tit

24/12/27(금)완료했는지 안했는지를 먼저 체크 (완료한 걸 확인할 수 있는 변수 필요)할 일을 완료해서 체크했을 때 true로 바뀌는 함수 필요URL을 읽어올 때 RequestParam을 받아, url로 판단하기\-> 완료여부는 할 일 목록을 체크하는 거니까 To

24/12/28(토) Todo - list 추가기능 특정 리스트의 할 일만 보기 1 리스트 따로 할 일 따로 조회 Request GET /todos Query params titleId 예: localhost:8080/todos?t

12/24/28(토)GET /lists/{listId}RequestPath paramslistId예: localhost:8080/lists/3ResponsebodyAPI를 보고 만들 수 있는 첫번째 일은 controller를 작성한다.todo가 현재 리스트 형태로 나와

25/1/2(목) 토스 브랜드콘 클론 카테고리 목록 조회 Method | URL GET | /categories Endpoints http://localhost:8080/categories Request : 전체가 보이기 때문에 x Response List

25/1/2(목)❗1:N의 관계에서 N이 1의 직접적인 정보를 가지고 있으면 안된다.아래의 수정된 것을 살펴보자product는 brand를 참조하고 있다. brand에는 brand의 name이 Entity의 객체로 가지고 있다. 따라서 product에 직접적으로 bra

25/1/다 대 다(N:M)인 관계에서는 관계매핑을 어떻게 사용할까?1:N관계에서 사용하는 어노테이션을 사용할 수 있다.하지만 이런 관계는 주로 사용하지 않는다고 한다.❗️클래스를 하나 더 만들어 1:N 관계로 만들어준다.즉, 브랜드와 카테고리는 다대다 관계이기 때문에

구인구직 서비스 구인 구직 서비스를 연습용으로 만들어보고자 함 설계 첫 아이디어 > 아이디어의 시작은 이러했다 내가 개발자를 고용하고 있으면 어떤 회사에서 개발자가 필요할 때 잠깐 빌려쓰는 형식이면 좋겠다. 왜? : 회사는 개발자를 고용하게 되면 많은 돈이 필요하니

Entity를 먼저 같이 설계한 후 API를 나눠서 작성하기로 했다.필요한 Entity는 개발자, 기업, 좋아요, 쪽지, 라고 생각했다.대충 생각하기로는 좋아요와 쪽지는 개발자id, 기업의 id를 가지고만 있으면 된다 생각해서, 1:N관계 그 이상도, 그 이하도 아니

개발자부분을 먼저 개발해보았다. 늘 하던대로 controller를 첫번째로 만들었다. api spec을 보고 만드는거라 크게 어렵지 않았다.service, repository를 그 다음에 만들었다. service를 만들면서 필요한 request들을 함께 만들었다.개발자

쪽지쪽지 생성쪽지는 내가 보낼 때 그 받는 쪽의 아이디가 c로 시작하는지, p로 시작하는지를 보고, 에러메세지를 띄우게 된다.저장할 땐, 내 id(기본 id, 로그인 id x)와 받는 사람의 id가 필요하다.response만 받는 사람의 id, 보낸 사람의 id, 기본

쪽지 조회의 문제점은 아래와 같았다.내가 보낸 쪽지 조회와 받은 쪽지 조회의 코드가 너무나도 유사하다. 개발자or기업의 이름때문에 저렇게 중복되는 코드를 작성해야하는걸까?일단 쪽지를 보낸 쪽지, 받은 쪽지를 나누었던 이유는 기능이 다르기 때문!그리고 if문으로 나눴던

쪽지 삭제의 문제점은 이러했다.구현되어 있는 쪽지 삭제는 내가 보낸 쪽지를 삭제하면 받은 사람의 쪽지도 같이 삭제되어버린다. 이게 맞을까? 놉!그래서 생각을 해본게첫번째 방법메세지를 생성할 때 하나의 메세지를 이쪽 저쪽 공유할 수 있는 user_id 칼럼을 만들자? 어

각 강의의 강사는 딱 한 명강사는 여러 개의 강의를 진행할 수 있음각 강의는 하나의 카테고리에만 속함 (카테고리: 국어, 수학, 영어, 과학, 사회)각 강의의 수강생은 여러 명수강생도 여러 강의를 수강할 수 있음. 단, 같은 강의를 여러 번 신청할 수는 없음내가 짠 A

API spec을 토대로 강의 부분을 먼저 작성하였다.강의 controllercontroller는 이제 api spec만 봐도 짤 수 있어야 한다.다른 dto, repository는 안적고 고민들과 구현된 코드만 작성해보도록 하겠다.강의 목록 조회강의 목록들에는 전체가

회원 controllerservice 부분도 강의 api와 비슷하게 작성했다.삭제도 delete방식을 사용해서 일단, hard delete방식으로 데이터베이스까지 삭제하기로 했다.수강신청 controller❓여기서 수강산청에 param을 사용한 이유?그냥,, 간단해서

강의 Entity에 deleted를 추가하고, fasle로 지정을 해놓는다.private boolean deleted = false; 왜냐하면 처음 강의가 생성될 때, delete가 true이게 되면 안보이기 때문이다.그리고 삭제가 되었다면 deleteBy라는 함수를

강의등록 시 기본적으로 비공개 상태비공개 상태조회: 목록 조회를 통해서는 조회되지 않음. 그러나 상세 조회를 통해서는 조회됨수강 신청 불가강의 공개특정 강의를 비공개 → 공개로 전환 (전환 후에는 목록 조회를 통해서도 조회됨) 나의 생각1\. 등록할 때는 기본적으로

강의 제목으로 검색 가능강사 이름으로 검색 가능검색 시 추가로 카테고리 가능검색같은 경우에 가장 많이 사용하는게 QueryDsl이다. 삼항 연산자를 사용하면 아주 편하다 근데 가독성이 떨어지면 많이 사용하지 않는다고 한다. 근데 지금 내 코드에서는 그렇게 가독성을 요구

페이징 한 페이지에 엄청나게 많은 양의 데이터를 한번에 주게 되면 굉장히 느려지게 된다. 따라서 한 페이지에 작은 수의 데이터만 보여줘서 관리한다. 그걸 페이징이라 부른다! 페이징은 다양한 방법이 있는데 QueryDsl로 페이징을 해줬다. 나는 기존에 QueryDsl

내가 맡은 부분은 상품 부분이다.Method: POSTPath: /productsExample Endpoint: https://localhost:8080/productsRequest Parameters:RequestHeader:adminToken (String

상품 등록 > 상품을 등록할 땐, 상품 옵션과 상품 옵션의 디테일까지 저장해야된다. 첫번째 방법 한번에 저장한다. 나는 처음에 그냥 option을 저장하면 될 줄알았다. 그냥 자연스럽게 될 줄 알았다. 그래서 적어봤던게

상품 수정은 상품들도 수정이 되고, 상품의 옵션도 수정이 되어야 한다.내가 시도한 방법은 어차피 상품 옵션은 서브 옵션을 알고 있으니까, (관계를 이미 설정을 해놨으니까) 상품 옵션을 상품과 오브젝트끼리 관계를 맺어줘야 된다고 생각했다. 그래서 아래와 같은 코드가 만들

저번의 문제는 등록까지는 어케어케 됐는데 상품 수정을 해결을 못했다. 연결이 왜 안되는지는 모르겠지만! 답답하니까 다른 방법을 생각해봤다.❓옵션을 하나로 생각옵션안에 옵션을 하니까, \~~한 문제가 생겼다. 지금으로서는 해결이 안됐다. 그래서 옵션을 하나로 관리하기로

JPA의 JPQL 또는 QueryDSL에서 연관된 엔티티를 한 번의 SQL 조회로 함께 가져오는 방법. SQL의 Join과 동일한 코드OneToMany관계에서 기본적으로 지연 로딩(Lazy Loading) 이 적용된 연관 엔티티들은 처음에는 조회되지 않고, 실제 사용할

CI는 테스트를 자동으로 해주는 깃허브 action의 한 종류이다.테스트 자동화 시스템이다.내가 CI를 구축하고, 실행했는데 내 local테스트에서는 잘 돌아가던 테스트가 CI를 거치니 에러가 난 상황이였다. 상황은 이렇다.이 테스트는 findAll했을 때 시간이 얼마