please #6
please #6
Conversation
| @PostMapping("/member/update") //redirect 해주는 역할 | ||
| public String update(@ModelAttribute MemberDTO memberDTO) { | ||
| memberService.update(memberDTO); | ||
| return "redirect:/member/" + memberDTO.getId(); | ||
|
|
||
| } | ||
| @GetMapping ("/member/delete/{id}") | ||
| public String deleteById(@PathVariable Long id) { | ||
| memberService.deleteById(id); // 목록상에서 삭제 | ||
| return "redirect:/member/"; | ||
| } |
There was a problem hiding this comment.
update 나 delete 같은 경우에는 나중에 PatchMapping, DeleteMapping으로 진행할 것 같습니다! 데이터는 POST 처럼 body로 넘어 갈꺼구요! 지금은 빠르게 만들어보는거라 좋습니다!
There was a problem hiding this comment.
넵 코드 정리해서 다시 pr 보내겠습니다!
There was a problem hiding this comment.
네! pr 이후의 코드는 커밋, 푸시만 해도 pr 에 바로 들어오니 참고해주세요!
There was a problem hiding this comment.
DTO는 임의로 생성하시는 class 인가요? 아니면 특정 라이브러리 규칙상 필수로 생성해야 하는 class 인가요?
There was a problem hiding this comment.
특정 라이브러리 규칙상 필수로 생성해야 하는 class는 아닙니다!
save.html에서 입력값을 받아 정보를 memberDTO에 저장하고 이를 DB에 저장하는 과정에서 memberEntity로 변환을 시키고 저장을 했습니다. 또한, DB에서 데이터값을 가져올 때는 반대로 memberEntity -> memberDTO로 변환을 시켜서 데이터를 가져왔습니다.
이렇게 하는 이유는 Entity 객체가 가지고 있는 데이터 중 사용자에게 보여주어야 하는 정보만을 필터링하거나, 데이터베이스에서 받아온 원시 데이터를 사용자가 이해하기 쉬운 형태로 가공하거나, 민감한 정보(예: 비밀번호)를 제외시키는 등의 작업을 할 수 있기 때문입니다. 또한, Entity 객체를 직접 사용하게 되면 데이터베이스 스키마 변경 등의 이슈로 인해 다른 계층에도 영향을 미칠 수 있습니다. 반면, DTO를 사용하면 이러한 영향을 최소화할 수 있습니다.
라고 GPT가 답했습니다.
제가 스스로 코드를 작성하는 능력이 부족했었기 때문에 강의를 찾아서 따라해봤을 때, 강사님께서 저런 형식으로
구조를 생성했습니다. 꼭 필요한 작업인지에 대해서 한 번 찾아보겠습니다!
There was a problem hiding this comment.
그러니까
Entity 는 DB에 접근하는 모델 객체인거고
DTO는 읽어온 데이터를 가공하는 기능을 제공하는 객체
로 짜 주신거군요! 좋은 구조로 보입니다.
이부분은 DTO 말고도 DAO도 있다고 운규님이 말씀해 주셨는데, 한번 찾아보시면 좋을 것 같습니다.
이런식으로 저는 전반적인 자바 코드에 관련된 리뷰 진헹하고, 운규님은 프레임워크 구조랑 사용방법에 대해 피드백 드릴 예정입니다~
| // dto -> entity 변환 | ||
| public static MemberEntity toMemberEntity(MemberDTO memberDTO) { | ||
| MemberEntity memberEntity = new MemberEntity(); | ||
| memberEntity.setMemberEmail(memberDTO.getMemberEmail()); | ||
| memberEntity.setMemberPassword(memberDTO.getMemberPassword()); | ||
| memberEntity.setMemberName(memberDTO.getMemberName()); | ||
| return memberEntity; | ||
|
|
||
| } | ||
|
|
||
| public static MemberEntity toUpdateMemberEntity(MemberDTO memberDTO) { | ||
| MemberEntity memberEntity = new MemberEntity(); | ||
| memberEntity.setId(memberDTO.getId()); | ||
| memberEntity.setMemberEmail(memberDTO.getMemberEmail()); | ||
| memberEntity.setMemberPassword(memberDTO.getMemberPassword()); | ||
| memberEntity.setMemberName(memberDTO.getMemberName()); | ||
| return memberEntity; | ||
| } |
There was a problem hiding this comment.
두 함수 로직이 사실상 같아 보이는데, getMemberEntity 로 통일하는 방법은 없었을까요?
그리고 잘 몰라서 여쭤보는건데, static 메소드로 계속 구성하는 이유가 있나요? 라이브러리 특성상 static 을 사용해야한다던가..
static 메소드 내부에서 객체 인스턴스인 new MemberEntity();를 계속 만드는데, 함수 호출할 때마다 인스턴스 만들고 리턴을 하는 로직이 필수인가 싶어 여쭈어봅니다.
There was a problem hiding this comment.
말씀하신대로 함수의 로직이 똑같고 getMemberEntity로 통일할 수 있습니다!
하지만 따로 따로 클래스를 만든 이유는 코드의 가독성과 유지보수성을 높이기 위해서입니다!
이렇게 따로 코드를 작성했을 때에 추후 로직이 변경되거나 추가했을 때에
해당 클래스만 수정하면 되기 때문입니다!
static 메소드로 계속 구성한 이유는 잘 모르겠습니다. 아직 객체에 대한 이해도가 부족하여 추가 공부 진행하겠습니다!
There was a problem hiding this comment.
아 그쵸 함수는 말씀해주신 대로 따로 2개 만들어야 할거 같긴합니다.
그러나
MemberEntity memberEntity = new MemberEntity();
memberEntity.setMemberEmail(memberDTO.getMemberEmail());
memberEntity.setMemberPassword(memberDTO.getMemberPassword());
memberEntity.setMemberName(memberDTO.getMemberName());
이 부분이 차후 추가 예정인 함수에서도 공통적으로 사용된다면 따로 빼도 좋을거 같다는 이야기 였습니다!
static 부분은 찾아보시고 다시 알려주시면 감사하겠습니다. 백엔드 스터디 잘 진행되고 있는거 같아 좋습니다!
2 participants
3주차 과제 완료했습니다!