TACO 프로젝트 회고록(2023-05-23)

윤현우·2023년 5월 23일
0

TACO 프로젝트 회고록

목록 보기
20/31
post-thumbnail

오늘은 간단하게 게시글 사용시 로그인 부분과 게시글의 사용언어 entity를 구현을 했다.

또, 회원가입 시 아이디 및 닉네임 중복 체크 버튼 없이 중복 체크를 하는 방법에 대해 찾아보았다.

jpa를 잘 다루지 못하는 나이기에 postEntity에 userIndex를 추가하여 해당 게시글이 사용자의 게시글인 것을 알 수 있게 해야했다.

그래서 가장 먼저 PostEntity를 수정하였다.

엔티티 수정

@Entity(name = "post")
@Getter
@Setter
@NoArgsConstructor
@AllArgsConstructor
@Builder
@Table
public class PostEntity {
    
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long postIndex;

    @Column(length = 1000)
    @NotNull
    private String title;

    @Column(length = 1000)
    @NotNull
    private String description;

    @CreationTimestamp //INSERT 쿼리가 발생할 때, 현재 시간을 값으로 채워서 쿼리를 생성한다.
    @Column
    private LocalDateTime postRegDate;

    @Column(length = 1000)
    @NotNull
    private String postSido;

    @Column(length = 1000)
    @NotNull
    private String postGugun;

    @Column(length = 1000)
    @NotNull
    private String postDong;

    @Column(length = 1000)
    private String postLanguage1;

    @Column
    private String postLanguage2;
    
    @Column
    private String postLanguage3;

    // 유저 인덱스
    @Column
    @NotNull
    private Long userIndex;

    public PostDto toDto() {
        PostDto postDto = PostDto.builder()
        .title(title)
        .description(description)
        .postRegDate(postRegDate)
        .postSido(postSido)
        .postGugun(postGugun)
        .postDong(postDong)
        .postLanguage1(postLanguage1)
        .postLanguage2(postLanguage2)
        .postLanguage3(postLanguage3)
        .userIndex(userIndex)
        .build();

        return postDto;
    }
}

이전의 PostEntity와 다른 점은 사용언어인 postLanguage를 3개로 늘렸다.

원래는 하나의 postLanguage 컬럼을 만들어 여러 데이터를 집어 넣으려했지만, 방법도 모르겠고, 찾아보니 관계형 DB에서는 한 컬럼에 여러 데이터를 넣는 것은 좋지 않다는 것을 알게 되었다.

그래서 그냥 컬럼을 여러개 만들고 Null이어도 되게 만들었다.

또한 userIndex를 컬럼으로 가져왔다.


게시글 작성 수정

Controller

다음으로 Controller의 게시글 작성 메서드를 수정하였다.

게시글을 쓰기 위해선 로그인이 필수이다.

하지만 로그인이 안되어있는 상태에서는 게시글 작성 url을 html에 넣어두지 않을 것이기 때문에, 로그인 체크를 따로 안해도 된다.

	@PostMapping("/post/save")
    public ResponseEntity<PostEntity> save(HttpSession session, @ModelAttribute("post") PostDto postDto){
        Long userIndex = (Long) session.getAttribute("userIndex");
        PostEntity post = postService.save(postDto, userIndex);    // 변경해야함( 테스트위해서 변경 )
        // postService.save(postDto, userIndex);
        
        return new ResponseEntity<>(post, HttpStatus.OK);
        // return "redirect:/post_detail.html";
    }

Long userIndex = (Long) Session.getAttribute("userIndex");

가장 먼저 게시글 저장 버튼을 누르려면 기본적으로 로그인 세션이 있는 상태일 것이다.

그래서 세션에서 사용자의 index를 가져온다.

PostEntity post = postService.save(postDto, userIndex);

그후 postService의 save 메서드로 작성된 게시글 정보와 userIndex를 파라미터로 넘긴다.

service

	public PostEntity save(PostDto postDto, Long userIndex) {
        PostEntity postEntity = postDto.toEntity(userIndex);
        PostEntity saved = postRepository.save(postEntity);

        return saved;
    }

파라미터로 받아온 postDto와 userIndex를 저장해야한다.

하지만 여기서 문제는 postDto와 userIndex는 따로 데이터가 온다는 것이다.

게시글을 userIndex를 추가해 저장하기 위해서는 userIndex를 postEntity에 추가해 저장해야 한다.

그래서 혼자 생각을 해보았다.

controller에서 service로 넘어갈때 Dto로 넘어가는데 repository에서는 해당 dto를 entity로 변경해 저장해야 한다.

그러면 dto에서 entity로 넘어갈 때 userIndex를 추가할 수는 없는건가라는 생각을 했다.

여기서 dto와 entity를 따로두는 이유는 모두가 알 것이다.

DTO와 Entity를 분리하는 이유

DTO(Data Transfer Object)는 Entity 객체와 달리 각 계층끼리 주고받는 우편물이나 상자의 개념입니다. 순수하게 데이터를 담고 있다는 점에서 Entity 객체와 유사하지만, 목적 자체가 전달이므로 읽고, 쓰는 것이 모두 가능하고, 일회성으로 사용되는 성격이 강합니다.

그래서 dto를 entity로, entity를 dto로 변경하는 메서드가 필요하다.

PostEntity

public PostDto toDto() {
        PostDto postDto = PostDto.builder()
        .title(title)
        .description(description)
        .postRegDate(postRegDate)
        .postSido(postSido)
        .postGugun(postGugun)
        .postDong(postDong)
        .postLanguage1(postLanguage1)
        .postLanguage2(postLanguage2)
        .postLanguage3(postLanguage3)
        .userIndex(userIndex)
        .build();

        return postDto;
    }

PostDto

public PostEntity toEntity() {
        PostEntity postEntity = PostEntity.builder()
        .title(title)
        .description(description)
        .postRegDate(postRegDate)
        .postSido(postSido)
        .postGugun(postGugun)
        .postDong(postDong)
        .postLanguage1(postLanguage1)
        .postLanguage2(postLanguage2)
        .postLanguage3(postLanguage3)
        .userIndex(userIndex)
        .build();

        return postEntity;
    }

만약 dto에서 entity로 변경할 때 파라미터로 userIndex를 넣으면 해당 userIndex를 엔티티에 추가할 수 있지 않을까 라는 생각으로 toEntity 메서드를 수정해보았다.

public PostEntity toEntity(Long userIndex) {
        PostEntity postEntity = PostEntity.builder()
        .title(title)
        .description(description)
        .postRegDate(postRegDate)
        .postSido(postSido)
        .postGugun(postGugun)
        .postDong(postDong)
        .postLanguage1(postLanguage1)
        .postLanguage2(postLanguage2)
        .postLanguage3(postLanguage3)
        .userIndex(userIndex)
        .build();

        return postEntity;
    }

toEntity메서드를 수정한 후, 서버를 돌려 postman으로 테스트를 돌려보았는데, userIndex가 잘 들어가있는 것을 확인할 수 있었다.


아이디 및 닉네임 중복 체크

이미 아이디 및 닉네임의 중복 체크 기능은 구현해두었다.

하지만 프론트 디자인 중, 회원가입 페이지에서 중복 체크 버튼이 없는 것이 더 디자인이 괜찮다는 얘기가 나와, 중복 체크 버튼 없이 중복 체크를 할 수 있는지 찾아보았다.

https://kimvampa.tistory.com/90

구글링 중 해당 페이지에서 해답을 찾을 수 있었다.

propertychange change keyup paste input

해당 js 기능은 html의 input 태그의 값을 실시간으로 처리할 수 있도록 하는 기능이다.

이 기능을 사용해서 ajax로 input 값을 보내 해당 아이디나 닉네임을 중복체크를 하게 한다.

만약 중복이라면 1을, 사용가능한 아이디나 닉네임이면 0을 반환해 사용가능을 확인하게 한다.


오늘은 생각보다 중요한 작업을 한것 같다.

확실히 로그인 구현은 여러가지를 생각하게 한다.

아직 중요한 작업들이 많이 남았다.

공부하다 생각한 것인데, 자기가 작성한 게시글이면 수정 및 삭제 버튼이 있어야하고, 자기가 작성한 게시글이 아니라면, 수정 및 삭제 버튼이 없어야 한다.

해당 게시글이 자신이 작성한 게시글인지 아닌지를 어떻게 판단해야 하는가에 대한 고민이었다.

이 고민은 차차 생각해봐야겠다.

profile
개발자가 되는 그날까지

0개의 댓글