개인사

개요MVC 아키텍처에서 Controller는 애플리케이션의 사용자 인터페이스 로직과 비즈니스 로직을 연결하는 중요한 구성 요소이다.클라이언트의 요청을 받아 처리하고, 서비스 계층의 비즈니스 로직을 호출한다.요청된 데이터를 가공하고, 적절한 응답을 반환한다. 주요 기능으로 HTTP 요청 처리, 요청 파라미터 매핑, 서비스 메서드 호출, 응답 데이터 포맷팅 등이 있다.HTTP 요청의 타입에 따라 매핑할 주소를 입력하면, 클라이언트는 해당 주소로 API 호출 요청을 보낼 수 있다.하기엔 무인 사물함 프로젝트를 진행하며 작성한 컨트롤러 정보이다. AdminController.javapackage com.a207.smartlocker.controller;import com.a207.smartlocker.mode..

개요MVC 아키텍처에서 Repository는 데이터 접근 및 영속성 로직을 캡슐화하는 중요한 구성 요소이다.데이터베이스는 데이터베이스나 다른 저장소와 직접적인 상호작용을 담당한다.주로 CRUD작업을 수행하며 비즈니스 로직과 데이터 액세스 로직을 분리하여 관심사의 분리를 실현한다. 데이터 접근 메서드들을 인터페이스로 정의하여 일관된 데이터 조작 방식을 제공한다.모델 객체의 상태를 데이터베이스에 반영하거나, 데이터베이스에서 모델 객체로 데이터를 변환한다. SpringBoot에서는 실제 쿼리를 통한 로직 구현 뿐만 아니라 Create와 Update를 진행해 주는 save와 findById를 통해 특정 레코드를 탐색하는 작업을 별도의 기능 작성 없이 사용할 수 있다. 하기에 레포지토리 인터페이스를 오름차순에 따..

개요Model에 속하는 DTO는 Entity와 다르게 클라이언트와 소통을 할 때 사용한다.클라이언트로 전달 받은 Post요청의 RequestBody항목들을 파싱하는데도 사용하며클라이언트로 응답을 보낼 데이터를 정의하고 전달하는 용도로도 사용한다. DTO는 Entity와 달리 API가 추가 될 경우 지속적으로 추가될 가능성이 많다.DB작업을 통해 필요한 데이터만 보낸다는 느낌으로 이해하면 될 것 같다. 예를 들어 회원 정보 수정과 같은 내용을 생각해 보자클라이언트로 부터 받아야 할 데이터는 ID, 비밀번호, 닉네임, 이메일 등이 있을 것이다.그렇다면 클라이언트로 부터 온 Request정보를 우선 DTO로 받아준다.DB작업 이후 클라이언트에게 응답을 다시 보내줄 때는 성공 여부만 리턴해 주면 될것이다.이 처..

개요프로젝트 명세를 기준으로 SpringBoot 서버에서 사용할 MVC모델을 제작해 보자이번엔 MVC 중 M에 해당하는 Model에 대한 정의를 할 것이다.그 중에서도 DB 도메인을 그대로 따올 Entity에 대해 작성해 본다.Entity는 DB의 테이블 정보 중 각 속성을 도메인에 맞게 파싱에 오는 느낌으로 보면 된다.따라서 DB에 수정사항이 없을 경우 한번 정의해 놓은 Entity는 변경될 일이 없다. 우선 관련 ERD를 먼저 참고해야 한다.해당 ERD를 기준으로 Entiy를 작성해 준다.단, RDBMS를 PosgreSQL로 선택하였으므로 일부 내용이 다를 수 있다.Entity를 가나다 순으로 오름차순 하여 작성하겠다. AccessToken.javapackage com.a207.smartlocker..

개요주제가 AIoT프로젝트인 만큼 웹 기술적인 면에서 API의 종류가 많거나 하지는 않다.따라서 사용자 페이지 이외에도 사용 이력 조회, 로봇 상태 조회, 유저 정보 조회, DAU, MAU 조회 등 관리자를 위한 페이지를 만들기로 명세하였다.관리자 명세는 하기와 같다. 관리자 로그인 기능 명세클라이언트에서 adminId와 adminPassword를 전달받는다.관리자 목록 테이블에 adminId가 존재하며 adminPassword가 일치한다면 로그인 성공 메시지를 리턴한다.만약 일치하지 않는다면 관련 메시지를 리턴하고 예외를 던져준다. 로봇 정보 출력 명세클라이언트로 부터 관련 요청이 올 경우 로봇 테이블에 존재하는 로봇 관련 칼럼 데이터를 모두 가져온다.클라이언트에게 로봇Id, 로봇이름, 작업 완료 횟..

개요지난 기간동안 프로젝트 명세와 ERD 등 많은 변경 사항이 생겼다.따라서 해당 명세에 따라 DB 생성 조건이 변경되었다.우선 사용자 관점에서의 명세는 아래와 같다. 사물함 조회 명세사물함 위치에 따른 버튼 클릭 시 사물함 현황을 노출시킨다. A, B, C섹터가 존재한다.특정 섹터 터치 시 해당 섹터의 사물함 정보를 DB에서 가져와 클라이언트에 리턴해준다.각 섹터마다 60개의 사물함이 존재하며 사물함 Id는 곧 사물함 번호가 된다.lockerStatusId가 1인 경우 사용 가능, 2인 경우 사용 중, 3인 경우 수리 중으로 명시한다.해당 값을 통해 사용자가 보관 요청 탭을 클릭할 경우 사용 중이거나 수리 중인 사물함의 경우 클라이언트에서 터치 불가, 회색으로 명시 등 사용자에게 선택할 수 없음을 명..

개요[AIoT] 무인 사물함 프로젝트 논리적 DB 설계, ERD 작성 [AIoT] 무인 사물함 프로젝트 논리적 DB 설계, ERD 작성개요실제 백엔드 로직을 작성하기 앞서 프로젝트 명세에 대해 많은 시간을 할애했다.주제가 정해진 이후 매일 30분 정도의 스크럼을 통해 각자 파트에서의 기능 구현에 대해 발표했다.그 중 DB의zzzz955.tistory.com 위 포스팅에서 만든 논리적 DB를 기반으로 물리적 DB를 설계하였다.엔터티 정보와 관계를 토대로 AI에게 부탁하니 PostgreSQL 환경에서의 SQL문을 모두 작성해 주었다.이를 토대로 테이블 생성 및 관계 설정, 인덱스 설정까지 한번에 설계가 가능해 졌다. 세상 참 좋아졌다. 다만, AI에게 요청 시 FK를 고려하여 테이블 생성에 따른 우선순위를 ..

개요실제 백엔드 로직을 작성하기 앞서 프로젝트 명세에 대해 많은 시간을 할애했다.주제가 정해진 이후 매일 30분 정도의 스크럼을 통해 각자 파트에서의 기능 구현에 대해 발표했다.그 중 DB의 경우 모든 파트가 만족할 만한 설계가 완료되어야 하기 때문에 가장 오랜 시간이 걸렸다. 로그인 및 회원가입 구현 여부에 대해서도 계속 결정이 번복되었다.사용자 별 사물함 사용 횟수 및 이용 시간과 그에 따른 혜택 지급을 해주기 위해선 필요했다.하지만 회원가입을 통해 구현할 수 있는 내용이 그것 뿐이라 결국 스펙에서 제거하기로 결정했다. 이 처럼 얽히고 설킨 끝없는 회의를 통해 결국 테이블 구조를 확정짓게 되었다.동작에 필요한 객체를 각 엔터티 마다 id를 PK로 사용하여 정의하였다.이후 정규화 과정을 통해 종속성이 ..

개요무인 사물함을 구현하는 AIoT 프로젝트를 시작하였다.프로젝트 인원은 총 6명으로 임베디드 2명, 프론트엔드 2명, 백엔드 2명으로 구성된 팀이다.임베디드를 공부하긴 했지만 백엔드 쪽에 관심이 더 생겨 나는 백엔드 파트를 맡게 되었다. 여태 개인 프로젝트만 진행하다 팀 프로젝트를 처음으로 진행하게 되어 걱정 반 기대 반인 상태이다.프로젝트 명세를 데드라인까지 성공적으로 구현하고 좋은 결과를 도출하면 좋겠다. 아이디어프로젝트 주제를 정의하기 까지 수 많은 아이디어가 오고갔다.무엇보다 AI요소를 접목하여 자율주행이 가능한 IoT를 개발해야 한다는 것이 주제 선정에 크게 애를 먹였다. 삼성의 볼리처럼 가전용 기계가 방을 순회하며 온습도 및 에어컨 등을 자동으로 틀어주는 로봇공장 재고파악을 자동으로 해주는..