API 개발 기본 - 회원 수정 API해당 강의 시리즈를 들으며 전 강의부터 생겼던 궁금한 사항에 대해 질문을 드립니다. 예제의 경우는 최대한 간단하게 간소화시킨 엔티티를 예시로 들었지만, 필드가 많은 엔티티의 경우에는 어떤 방식으로 업데이트를 하는지 감이 잡히질 않네요. // java @RequestMapping(value = "/v1/edit/{memberId}", method = RequestMethod.PUT) public EditMemberResponse editMemberV1(@PathVariable Long memberId, @RequestBody @Valid EditMemberRequest request) { memberService.update(memberId, request.getName()); ... return new EditMemberResponse(member); }강의 내용 중 위와 같이 업데이트 파라미터에 DTO 필드를 받아 업데이트 하도록 서비스를 작성하셨는데, 단순히 이름만 있는 엔티티 클래스가 아닌 필드가 굉장히 많은 엔티티의 경우에는 어떤식으로 업데이트 처리하는 것이 효율적일지 궁금해서 질문을 드립니다. @Entity public class Temp { @Id @GeneratedValue private Long id; private String field01; private String field02; // ...무수히 많은 필드들 private String field66; private String field67; } 예를들어, 위와 같은 Temp 클래스의 경우를 업데이트 하기 위해 앞서 설명한 방식으로 업데이트 기능을 서비스계층에 구현한다면 아래와 같이 실질적으로 사용이 불가능할정도로 가독성과 생산성이 떨어졌습니다.// java tempService.update( editTempRequest.getField01(), editTempRequest.getField02(), editTempRequest.getField03(), editTempRequest.getField04(), ..., editTempRequest.getField67() ); 아래와 같이 서비스 계층에 EditTempRequest DTO 계층 클래스를 직접 넘기는 방법도 생각을 해보았습니다만, 서비스 계층에서 DTO 클래스를 이용하기 위해 컨트롤러 계층에서 이너 클래스로 선언된 DTO를 별도의 public 클래스로 선언해주어야 되므로 별도의 자바 파일과 패키지를 구성하게 되어 불필요한 복잡도가 증가하는 문제가 발생했습니다. 또한, 단순히 요청, 응답을 위해 데이터를 담는 목적으로 사용되어야 하는 DTO 클래스의 역할과 책임이 확장되는 문제도 생겼습니다.// java import com.wahhahaha.controller.dto.editTempRequest; ... tempService.update( editTempRequest ); 클라이언트 측에서 수정 API를 호출하기 전에 조회 API를 우선 호출하여 각 필드 정보를 가진 상태로 전체 필드를 이용한다면 merge 업데이트로 쉽게 해결이 가능하겠다라는 생각을 해보긴 했지만 merge는 가급적 이용하지 않는 편이 좋다는 전 강의 내용이 있어 혼란스럽네요.

부트스트랩 파일 다운로드해서 임포트하는 과정에서 업데이트 필요해보입니다

혹시 샤딩 구성에 대해서 강좌 업데이트나 추가 계획은 없으실까요?   데이터 베이스를 분산으로 인프라를 구축할때 결국 샤딩을 생각해야 하는데 docker를 기반으로된 예제가 더 추가되면 실무에 적극 사용할 수 있을것 같아서 문의 드립니다.