RestApi 게시판 CRUD 만들기 (1)

CRUD 기능만 있는 게시판을 연습해보았다.

어떤 서비스든 CRUD 기능이 없는 애플리케이션은 없을 것이고, 그만큼 기초가 되는 부분이라고 생각한다.

 

• Entity 클래스인 Post.class 에서는 @setter 를 사용하지 않았다.
• 예외처리, 유효성, 로그인 등 다른 기능은 모두 제외했다.
• 화면을 구성하지 않았으며 테스트와 포스트맨으로 기능이 정상작동하는지 확인했다

 

패키지 구조설계는 계층형 패키지가 아닌, 도메인형 패키지 구조로 진행했다.

post 밖에 없지만, 복잡한 애플리케이션에서는 도메인형 패키지가 더욱 가독성이 좋다고 생각한다.

 

계층형은 controller , service , repository 이렇게 나눈다

복잡해지면 많은 controller 패키지에서 내가 원하는 controller 를 찾기 어려울 것이다.

 

도메인형은 말그대로 도메인대로 나눈다. ex) member, post ..

복잡해지면 내가 원하는 도메인에 들어가 찾을 수 있다.

계층형 / 도메인형 패키지 구조 차이

 

먼저 , 내가 만든 최종 패키지는 아래와 같다.

 

---

Post

@Entity
@Getter
@NoArgsConstructor(access = AccessLevel.PROTECTED)
public class Post {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;
    private String title;
    private String content;

    @Builder
    public Post(Long id, String title, String content) {
        this.id = id;
        this.title = title;
        this.content = content;
    }

    public PostConvert toConvert() {
        return PostConvert.builder()
                .title(title)
                .content(content)
                .build();
    }

    public void update(PostConvert postConvert) {
        this.title = postConvert.getTitle();
        this.content = postConvert.getContent();
    }
}

• PK 가 될 id 와 나머지 title, content 를 선언해주었다.
• Enttiy 클래스에서는 @Setter를 사용하지 않고, 생성자를 따로 생성했다. 
  빌더 패턴을 사용했으며, 사용한 이유는 간단히 아래와 같다.
   - 가독성이 좋다.
   - 필요한 파라미터만 생성할 수 있다.
• toConvert 매소드는 service에서 update 메서드를 생성할때 사용한다.
• update 메서드 또한 service에서 update 메서드를 생성할때 사용한다.

---

PostRespository 

package com.practice.postprac.domain.post.repository;

import com.practice.postprac.domain.post.Post;
import org.springframework.data.jpa.repository.JpaRepository;

public interface PostRepository extends JpaRepository<Post, Long> {
}

 

• spring data JPA 사용해서 생성해준다.
• 보편적인 CRUD 기능을 제공해준다.

---

PostsService 를 생성하기 전에 먼저 등록,수정,응답에 필요한 클래스를 만들어준다.

먼저 등록, 수정 그리고 형변환에 관련된 Convert를 생성한다.

 

 

CreatePostDto

@Data
@NoArgsConstructor
public class CreatePostDto {

    private String title;
    private String content;

    @Builder
    public CreatePostDto(String title, String content) {
        this.title = title;
        this.content = content;
    }
}

• Post 를 생성하기 위한 Dto 

 

UpdatePostDto

@Data
@NoArgsConstructor
public class UpdatePostDto {

    private String title;
    private String content;

    @Builder
    public UpdatePostDto(String title, String content) {
        this.title = title;
        this.content = content;
    }
}

• update 할때는 title 과 content 를 수정할 수 있도록 설정했다.
• createPostsDto 와 똑같이 생겼지만, 따로 나눈 이유는 이후 서비스에서 조건이 변경될 수 있기 때문이다.
  ex) 같이 사용했는데 createPostsDto 에 email 필드가 추가된다면? -> 다시 리팩토링이 필요하다.

 

PostConvert

@Data
@NoArgsConstructor
public class PostConvert {

    private String title;
    private String content;

    @Builder
    public PostConvert(Long id, String title, String content) {
        this.title = title;
        this.content = content;
    }
}

이후 update service 를 작성할 때 사용되며,  사용용도는 아래와 같다.

• 수정할 게시글을 찾는다 -> 형태 : post
• post 에는 setter 가 없으므로 값 변경이 불가능하다
• post 를 PostConvert 형태로 변경한다
• 이후 set 메서드를 이용해 updatePostDto 에 입력된 값으로 변경한다.
• post 의 update 메서드를 통해 변경완료

service 클래스에서 어떤식으로 흘러가는지 확인할 수 있다.

 

---

응답받을 클래스를 만든다.

 

PostsReponse

@Data
@NoArgsConstructor
public class PostsResponse {

    private Long id;
    private String title;
    private String content;

    @Builder
    public PostsResponse(Long id, String title, String content) {
        this.id = id;
        this.title = title;
        this.content = content;
    }

    public PostsResponse(Post post) {
        this.id = post.getId();
        this.title = post.getTitle();
        this.content = post.getContent();
    }
}

Post 클래스와 다른 필드값은 없지만, 이후 서비스가 변경될 경우를 대비해 응답클래스를 따로 작성한다.