- 당연히 구글링 해보셨져? 원하는 결과를 못찾으셨나요? 어떤 검색어를 입력했는지 알려주세
- 문제가 발생한 코드(프로젝트)를 Github에 올리시고 링크를 알려주세요.
Editor관련한 질문글들을 읽어보아도 제 머리로 이해가 안돼서 또 이렇게 Editor 질문 글을 하나 더 추가합니다... ㅠㅠ
[해당 영상을 보지 않았더라면 짰을 코드]Post엔티티에 비즈니스 로직을 작성하고
단순하게 PostEdit을 전부 넘겨 비즈니스 로직 change를 호출하여 더티체킹으로 마무리! 이렇게 했을 경우, 파라미터 순서에 무관하게 PostEdit이라는 수정을 위한 Dto 객체를 단 하나만 넘겨 수정을 할 수 있다고 판단했습니다. 물론 위 비즈니스 로직은 null값에 대처는 못하겠지만요! 하지만, 프론트 개발자와 상의하여 '수정 시, 모든 데이터를 넘겨준다는 전제' 에서는 가장 간단한 방법이라고 생각했습니다!
[Editor를 작성해보며 느낀 의문점]Post의 toEdit을 통해 기존 가지고 있던 데이터를 PostEditor에게 넘김으로써 Builder에서 null값에 대응할 수 있다는 점 이외에는 또 다른 장점을 이해하지 못하고 있습니다. Request의 title혹은 content가 null일 경우 이를 해결하기 위한 방법을 제시해주는 것 말고는 되려 관리해야 할 것들만 늘어난 느낌이 해소가 되지 않습니다 ㅠㅠ 그래서 제가 이해한 것 까지의 내용들이 잘 이해한 것인지 그리고 추가적으로 제가 이해하지 못한 것들을 이해하고 싶습니다!
- findById로 수정하려는 엔티티를 가져옵니다.
- toEdit()을 통해 현재 수정하고자 하는 엔티티의 필드들을 PostEditor에게 넘겨 빌더를 만듭니다. 이는 수정하려는 엔티티가 현재 가지고 있는 필드들을 핸들링 할 수 있도록 해줍니다. (가령, title혹은 content의 null 처리)
- 2번을 통해서 PostEditor가 현재 수정하려는 Post의 필드들을 주입 받았으면, Request로 받은 데이터를 통해 최종 build()를 해줍니다.
- 변경사항을 모두 적용한 postEditor를 Post의 변경비즈니스 메서드 edit(postEditor)를 통해 더티체킹으로 변경해줍니다.
[최종적으로 든 생각][Editor를 작성해보며 느낀 의문점] 에서 작성된 것들이 정확하다면,아예 첫 방법을 사용하되, 비즈니스 메서드에서 null 체크를 해주면 어떨까? 하는 생각이 들었습니다.
이런 방식으로 진행한다면 문제가 있을까요? 긴 글에 시간 내어주셔서 감사합니다 !
안녕하세요. 호돌맨입니다.
PostEdit은 web(presentation layer) 계층입니다.
Post가 표현 계층을 알 필요가 없기 때문에 구분되어 있습니다.
또한 수정할 수 있는 범위를 최소화 하기 위해 PostEditor를 제약을 두고있습니다. (PostEditor에는 수정할 수 있는 field만 들어갈 수 있으니깐요)
감사합니다.