상품 수정하기 상품 수정 기능은 “어떤 상품을 수정할 것인가”와 “무엇으로 수정할 것인가”라는 두 가지 정보가 함께 필요하다.여기서 어떤 상품을 수정할지는 URL 경로에 있는 상품 번호(id)로 결정하고,실제 수정할 데이터는 요청 바디에 담긴 ProductDto로 받는 구조를 사용한다. 컨트롤러 코드는 다음과 같다. @RequestMapping(value = "/products/{id}", method = RequestMethod.PUT)public ProductDto updateProduct( @PathVariable Long id, @RequestBody ProductDto productDto){ productDto.setId(id); return simpleProductS..
상품 조회 기능 구현하기 상품 조회 기능의 요구 사항은 다음과 같이 할 수 있다. ① 상품 번호를 기준으로 하나의 상품을 조회할 수 있어야 한다. ② 전체 상품 목록을 조회할 수 있어야 한다. ③ 상품 이름에 포함된 특정 문자열을 기준으로 검색할 수 있어야 한다. 상품 번호를 기준으로 하나의 상품을 조회 상품 관리 기능에서 가장 기본적인 조회는 특정 상품 하나를 가져오는 것이다. 이때 기준이 되는 값은 상품 번호, 즉 id다.상품 번호는 각 상품을 구분하는 고유한 값이기 때문에, 단건 조회는 자연스럽게 id 기준으로 구현하게 된다. 먼저 레포지토리에서는 리스트 안에 저장된 상품들 중에서,요청으로 들어온 id와 같은 값을 가진 상품을 찾아야 한다. public Product findById(Long..
DTO 처음 상품 관리 애플리케이션을 만들 때는 Controller와 Repository 모두에서Product 클래스를 그대로 사용해도 크게 문제 없어 보일 수 있다. 하지만 애플리케이션이 조금만 커지면 이 구조의 한계가 드러난다.가장 큰 문제는 외부와 내부가 너무 강하게 연결된다는 점이다. 컨트롤러는 애플리케이션의 외부 접점이다.즉, 브라우저나 Postman 같은 클라이언트가 직접 데이터를 주고받는 곳이다.그런데 컨트롤러가 내부 도메인 객체인 Product를 그대로 사용하고 있으면,내부 구조의 변화가 외부에 바로 노출될 수 있다. 예를 들어 Product 클래스에 필드가 추가되거나 이름이 바뀌면,그 영향이 곧바로 API 응답 형식이나 요청 형식에도 반영될 수 있다.즉, 내부 구조를 조금 바꾸는 것만으..
컨트롤러 만들어보기 레이어드 아키텍처를 적용하기 전에, 먼저 가장 단순한 형태로 컨트롤러를 만들어보면스프링이 요청과 응답을 어떻게 처리하는지 감을 잡기 좋다. ProductController를 만들고, POST /products 요청을 받아 Product 객체를 그대로 반환한다고 해보자. @RestControllerpublic class ProductController { @RequestMapping(value = "/products", method = RequestMethod.POST) public Product createProduct(@RequestBody Product product){ // product 저장하는 부분 return product; }} ..
