- DispatcherServlet은 class의 annotation 유무를 보고 구분을 한다 실제 코드는 Github 링크를 참고하면 된다! 아래는 예제 프로젝트의 파일들이다. 딱 보니, 여러 개의 controller와 Spring의 @RequestMapping이 보인다 프로세스 public static void main(String[] args) throws Exception { Scanner sc = new Scanner(System.in); String uri = sc.nextLine(); Set classes = componentScan("ex03"); findUri(classes, uri); } 처음 프로젝트를 실행시키면, URI 입력 받고, 입력 받은 데이터를 잘라서 findURI에 넣는다 ..
카카오테크캠퍼스
DispatcherServlet 왜 필요한가 **요약** - DispatcherServlet은 모든 웹 요청에 대해 적절한 Controller로 라우팅을 해준다 예제 코드를 분석하면서 DispatcherServlet이 왜 필요한가 알아봅시다 아래 코드는 RequestMapping 어노테이션을 사용하여 특정 URI를 메서드에 연결하고 있습니다. 이는 스프링 프레임워크의 RequestMapping과 유사한 동작을 수행합니다. 코드 분석 public class App { public static void findUri(UserController uc, String uri) throws Exception { boolean isFind = false; Method[] methods = uc.getClass().g..
생성자 Vs 빌더 패턴 1. 생성자(Constructor) 사용하기 CartRespFindAllDTO responseDTO = new CartRespFindAllDTO(productDTOList, 104500); 생성자를 사용하면 객체를 만들기 위해 필요한 파라미터를 모두 제공해야 합니다. 생성자를 통한 객체 생성은 간단하고 직관적입니다. 위 예시에서는 productDTOList와 104500이라는 두 개의 파라미터를 이용해 CartRespFindAllDTO 인스턴스를 생성합니다. 단점은 생성자에 전달된 파라미터의 순서나 의미를 즉시 이해하기 어려울 수 있습니다. 또한, 파라미터의 수가 많아지면 관리하기 어려워집니다. 2. 빌더 패턴(Builder 패턴) 사용하기 CartRespFindAllDTO res..
Builder 패턴 Builder 패턴은 객체 생성에 관련된 디자인 패턴으로, 객체를 생성하는 방법과 표현하는 방법을 분리하여 동일한 생성 절차에서 서로 다른 표현 결과를 만들 수 있게 합니다. DTO에 Builder를 사용하는 주요 이유는 다음과 같습니다: 1. 가독성 향상 객체 생성시에 원하는 매개변수를 선택적으로 입력하고 가독성 좋은 코드를 작성할 수 있습니다. 생성자에 많은 수의 매개변수가 있는 경우, 어떤 값이 어떤 변수에 할당되는지 이해하기 어렵습니다. 반면, Builder 패턴을 사용하면 각 변수에 어떤 값이 설정되는지 명확하게 파악할 수 있습니다. // Without Builder Product product = new Product(1, "Book", 1500, "Good book", "..
🐥 카카오테크캠퍼스 - 2단계 2주차 과제 - 고려사항 요구사항 전체 API 주소 설계 API 요구사항 반영 API 명세를 위해 고민한 것들 Mock API Controller 구현 Spring Boot 컨트롤러 작성 완성된 소스코드 제출 1. 전체 상품 목록 조회 - Method : Get - Local URL : http://localhost:8080/products - Param : page={number} 구현 사항 findAll(@RequestParam(defaultValue = "0") int page) 전체 상품 목록 조회 API는 Parmeter를 통해 페이지네이션을 고려하고 있습니다 default value를 주어 페이지별 상품 조회도 가능하도록 하였습니다 Controller @GetMa..
🐥 카카오테크캠퍼스 - 2단계 2주차 과제 - 예외처리 1. 전체 상품 목록 조회 Method : Get Local URL : http://localhost:8080/products Param : page= @GetMapping("/products") public ResponseEntity findAll(@RequestParam(defaultValue = "0") int page) { List responseDTO = new ArrayList(); // 상품 하나씩 집어넣기 responseDTO.add(new ProductRespFindAllDTO( 1, "기본에 슬라이딩 지퍼백 크리스마스/플라워에디션 에디션 외 주방용품 특가전", "", "/images/1.jpg", 1000 )); responseDT..
🐥 카카오테크캠퍼스 - 2단계 2주차 과제 과제 분석 요구사항 🐥 카카오테크캠퍼스 - 2단계 1주차 Entity 최종 설계에서 제공 받은 API 명세와 똑같은 응답 반환하는 Controller 구현 Data는 Dummy를 임의로 만들어서 구현 필수 제출 사항 API 주소 설계 소스 코드 API 구현 1. 전체 상품 목록 조회 Method : Get Local URL : http://localhost:8080/products Param : page= @GetMapping("/products") public ResponseEntity findAll(@RequestParam(defaultValue = "0") int page) { List responseDTO = new ArrayList(); // 상품 하나..
🐥 카카오테크캠퍼스 - 2단계 1주차 Entity 최종 설계 - 부족한 기능에 대한 요구사항을 미리 예상할 수 있는가? - (예를 들면 상품등록 api가 기존 요구사항에는 없는데 추후 필요하지는 않을지, 이런 부분들을 생각하였는지) - 요구사항에 맞는 API를 분석하고 사용자 시나리오를 설계하였는가? - (예를 들어 배포된 서버와 화면 설계를 제시해줄 예정인데, 특정 버튼을 클릭했을 때 어떤 API가 호출되어야 할지를 아는지) - 응답되는 데이터가 프론트앤드 화면에 모두 반영될 수 있는지를 체크하였는가? - (예를 들어 배송관련 비용이 있는데, 이런것들이 API에는 없는데 이런 부분을 캐치할 수 있는지) - 테이블 설계가 모든 API를 만족할 수 있게 나왔는가? - (테이블이 효율적으로 나왔는가 보다는 ..
🐥 카카오테크캠퍼스 - 2단계 1주차 Entity 세부 설계 🐥 카카오테크캠퍼스 - 2단계 1주차 Entity 기본 설계에서는 API 요청 응답에 따라 테이블을 예측해서 작성해 보았습니다 오늘은 화면 설계서와 기본 설계 과정에서 만들었던 테이블을 최적화하는 시간을 가졌습니다. User(사용자) Request Body를 보면 유저 이름, 이메일, 비밀번호가 필요하다 { "username" : "meta", "email" : "meta@nate.com", "password" : "meta1234!" } - id : PK - userName : 유저 이 름 - email : 이메일 - password : 비밀번호 - createDate : 생성 날짜 - updateDate : 수정 날짜 Product(상품) ..
조회 Vs Join 무엇이 더 효율적인가 🐥 카카오테크캠퍼스 - 2단계 1주차 과제 분석을 하고 있는데, 자연스럽게 조회와 Join 중 무엇이 효율적인가 고민하게 되었습니다 사실 그냥 만드는거라면, 쓱쓱 만들면 되는데 그런게 아니라 대용량 처리나 잦은 조회 등의 문제도 생각해보고 싶었습니다 일단 조회(DB Lookup)와 조인 연산은 관계형 데이터베이스에서 수행하는 일반적인 작업입니다. 둘 다 데이터베이스로부터 정보를 검색하는 방법이지만, 특정 시나리오에 따라 성능에 다른 영향을 미칠 수 있습니다. 1. 데이터베이스 조회 (DB Lookup) DB Lookup은 특정 데이터를 찾기 위해 데이터베이스의 단일 테이블을 쿼리하는 것을 포함합니다. 예를 들어, Customers 테이블이 있고, ID로 고객의 세..
