나만의 일정 관리 앱 서버 만들기

드디어 내 첫 Spring 개인 과제를 할 시간이다.

나만의 일정 관리 앱 서버를 만들라고 하셨다.

 

일단 Use Case Diagram부터 그려볼게요.

 

근데 그게 뭔데?

쉽게 말해서 시스템과 사용자의 상호작용을 다이어그램으로 표현한 것

여기서 또 중요한 게 있는데 관계라는 것이 존재한다.

 

벌써 막막하다

 

1.Association(연관 관계)

그림 그대로 사용자가 이 앱에서 결제를 한다는 것을 나타내는 관계이다.

즉, 사용자와 앱의 상호작용을 나타낸다.

 

2. include(포함 관계)

'결제를 하려면 로그인이 필수이다'를 나타내는 그림이다.

하나의 기능을 하려 할 때 다른 기능이 꼭 동반되어야 하면 include를 사용한다.

 

3. extend(확장 관계)

이러한 결제 과정에는 여러 과정이 있겠죠?

현재 그림에선 결제를 진행할 때 카카오페이, 신용결제 등등 선택적으로 수행할 수 있는 것을 나타냅니다.

 

화살표 방향 유의해 주세요!

 

그럼 그려볼까요?

 

 

뭔가 모자란 것 같지만 그래도 봤을 때 유저랑 어떤 식으로 상호작용을 하는지 알 수 있는 것 같습니다.

 

이제 API 명세서를 작성해보도록 하겠습니다.

그게 뭔데?

 

API 명, 파라미터, 반환 값, 데이터 및 전달 형식 등 API를 정확하게 호출하고

결과를 명확히 해석하는데 필요한 정보들을 일관된 형식으로 기술한 것을 의미합니다.

 

벌써 어렵네요

해볼게요

 

 

그냥 제 생각대로 해봤는데 맞았으면 좋겠네요

 

 

이제 가장 어려울 것 같은 ERD 다이어그램을 작성해 보겠습니다.

ERD가 뭔데?

 

ERD는 구현해야 할 서비스의 영역별로 필요한 데이터를 설계하고 각 영역 간의 관계를 표현하는 방법입니다.

 

E (Entitiy, 개체) 

ex) 일정, 책, 저자, 댓글 등

 

A(Attribute, 속성) - 개체가 가지는 속성

ex) 일정 제목, 생성 날짜, 일정 내용 등

 

R(Relationship, 관계) - 개체들 사이의 관계를 정의

ex) 하나의 저자는 여러가지의 책을 가질 수 있다

 

벌써 어지럽네요.

해봅시다.

 

 

 

 

구현 할 프로젝트가 그렇게 큰 프로젝트가 아니라 개체가 하나 밖에 나오지 않아서 관계를 표현할 방법이 없었다.

 

 

일단 프로젝트를 만들고 데이터 베이스를 등록해주었다.

 

성공

 

먼저 Schedule entity를 구현해 보자

벌써 ERD 다이어그램에서 오류가 나기 시작했다..

id를 Long으로 사용하게 되는 불상사가 일어났다.

이렇게 수정할게요

 

 

 

내가 생각하는 중요한 부분은 키를 직접 만들지 않고 DB에 id를 만드는 것을 위임하는 코드이다.

이런 식으로 코드를 작성하면 자동으로 1씩 증가하며 중복되지 않는 id를 만들어준다.

 

 

JPA의 @Column 어노테이션을 통해 손쉽게 db table을 만들어주었다

 

 

그리고 큰 틀을 잡기 위해 폴더들을 생성하였다.

entity를 그대로 반환하지 않고 dto 타입으로 반환하기 위해 dto폴더를 만들었다.

 

그게 뭔데?

 

dto는 프로세스 간에 데이터를 전달하는 객체다.

즉 http 요청의 데이터를 전달받거나 계층(Controller, Service) 간의 이동 시에 사용되는 객체

 

dto를 사용하면 클라이언트로부터 Entity의 정보를 숨길 수 있으며

내부 DB구조를 변경하는 경우 코드를 유지보수하는데 유리합니다.

 

그리고 Controller, Service, Repository로 나누려고 한다.

 

 

 

Controller -> 클라이언트의 요청을 받고 로직 처리는 Service에게 전담

 

Service -> 비즈니스 로직을 가지고 있음, 요구사항을 처리, DB저장 및 조회가 필요할 때는 Repository에게 요청

 

Repository -> DB관리, CRUD 작업

 

이런 식으로 폴더를 나눴다.

 

 

컨트롤러부터 보자

 

 

이런식으로 선언이 되어있다.

근데

 

 

어디서도 호출을 해서 값을 넣어주지 않는데 어떻게 실행이 되는 걸까?

 

@RestController로 인해 자동으로 주입되기 때문이다.

 

이걸 의존성 주입이라 한다.

 

@(Rest) Controller, @Repository, @Service 등의 어노테이션이 붙은 클래스는 Spring 콘텍스트에 의해 관리되는 빈으로 등록된다.

 

쉽게 말해서 new ScheduleService()를 자동으로 넣어주고 있다고 보면 된다.

 

이렇게 왜 하는데?

 

개발자가 메서드나 객체의 호출을 결정하게 되면

데이터가 변경될 때마다 하나씩 변경해서 넣으려면 엄청나게 많은 코드 변경이 일어난다.

 

제어의 역전(IOC)을 시키기 위해서다. 메서드나 객체의 호출을 개발자가 결정하지 않고,

외부에서 결정되도록 바꾸는 것이다.

 

객체의 의존성을 역전시켜 결합도를 줄이고 유연한 코드를 작성할 수 있어 가독성 및 코드 중복, 유지 보수가 용이하다.

 

즉 쉽게 말해서

원래 회원의 정보를 수정할 때 이름과 나이만 수정하도록 했다. 

하지만 비밀번호도 수정할 수 있도록 다시 개발을 해야 한다면?

 

클래스에 비밀번호도 받을 수 있는 생성자를 또 따로 생성하고 모든 연결되는 부분을 수정해야 한다.

 

하지만 위에서 말한 의존성 주입을 통해 bean이 외부에서 결정된 데이터로 객체를 만들어

자동으로 필요한 데이터들을 넣어주며 코드를 수정할 필요가 없고

개발자가 직접 객체를 관리하지 않는 제어의 역전(IOC)이 일어난다.

 

이게 이번 프로젝트의 핵심이라고 생각한다.

 

Controller는 이런 식으로 api 명세서에 맞게 또 Rest 하게 짜도록 노력헀다.

 

 

RequestDto는 이런 식으로

 

 

 

ResponseDto는 이런 식으로 구현하였다.

 

 

 

 

Service는 Controller에서 구현한 메서드들이 원하는 기능을 수행하도록 구현하였고

마지막으로 Schedule에서는 JPA를 통해

 

 

나만의 메서드를 만들어 쉽게 데이터 베이스에 접근하도록 하였다.

 

 

POSTMAN을 사용하여 테스트를 해보겠다.

 

 

먼저 스케줄 등록을 먼저 해보겠습니다.

 

복잡하고 공개되면 안 되는 비밀번호가 있기 때문에 Body에 JSON 형식으로 데이터를 받았다.

 

 

 

자동으로 id와 createTime이 생성되며 DB에 저장된다

 

 

 

id는 위에서 설명한 것처럼 하나씩 자동으로 올라가며 중복되지 않는다.

 

 

이제 특정 스케줄을 조회해 보겠다

 

 

간단하고 노출되어도 되는 id는 query으로 받았다.

 

 

전체 스케줄 조회는 request가 없다.

 

잘 나온다

 

 

특정 데이터 수정을 해보자

 

 

param으로 특정 id를 받고 body를 통해 수정할 내용을 보내고

비밀번호를 확인하기 위해서 비밀번호를 request 받는다.

 

 

수정 완료

 

 

 

마지막으로 삭제해 보자간단하다

 

 

param으로 특정 id를 받고 공개되면 안 되는 password는 body로 받고 검사한다.

 

 

 

 

전체 스케줄 조회에서 삭제한 1번 id가 삭제된 것을 확인할 수 있다.

 

 

아직 이해할게 많고 부족하지만 이렇게 코드 짠 것을 다시 보고 블로그에 정리하면서또 한 번 성장한 것 같다 화이팅

 

 

https://github.com/LeeChangHyeong/OwnCalendar

GitHub - LeeChangHyeong/OwnCalendar: 스파르타 코딩 클럽 첫 번째 Spring 개인 과제입니다 👨🏻‍💻