[WIL] 항해 Chapter 03 (2022.07.08~2022.07.14)

YOONG·2022년 7월 17일
0
post-thumbnail

Chapter 3 | 주특기 기본/심화

회원가입, 로그인, 댓글 작성/수정/삭제 기능이 추가된 나만의 항해 블로그 백엔드 서버 만들기

요구사항

  • 1) 서비스 완성, 2) AWS 배포 두 가지를 모두 완수해야 합니다.

1) 서비스 완성

  1. 프로젝트 구성
    • Springboot 2.6.9 이하 버전으로 프로젝트를 생성하세요
      • 현재 블로그, 강의자료 등 참조할 수 있는 레퍼런스들은 2.7미만에서 동작합니다. 2.7버전 이상에서 구현시 공식문서만 참조하여 구현하여야 합니다.
    • jwt 를 사용하여 로그인, 회원 기능을 구현하세요
      • 아래 요구사항에서 언급되는 토큰은 Jwt를 의미합니다.
  2. 회원 가입 API
    • 닉네임, 비밀번호, 비밀번호 확인을 request에서 전달받기
    • 닉네임은 최소 3자 이상, 알파벳 대소문자(a~z, A~Z), 숫자(0~9)로 구성하기
    • 비밀번호는 최소 4자 이상이며, 닉네임과 같은 값이 포함된 경우 회원가입에 실패로 만들기
    • 비밀번호 확인은 비밀번호와 정확하게 일치하기
    • 데이터베이스에 존재하는 닉네임을 입력한 채 회원가입 버튼을 누른 경우 "중복된 닉네임입니다." 라는 에러메세지를 response에 포함하기
  3. 로그인 API
    • 닉네임, 비밀번호를 request에서 전달받기
    • 로그인 버튼을 누른 경우 닉네임과 비밀번호가 데이터베이스에 등록됐는지 확인한 뒤, 하나라도 맞지 않는 정보가 있다면 "닉네임 또는 패스워드를 확인해주세요"라는 에러 메세지를 response에 포함하기
  4. 로그인 검사
    • 아래 API를 제외하고 모두 로그인 토큰을 전달한 경우만 정상 response를 전달받을 수 있도록 하기
      • 회원가입 API
      • 로그인 API
      • 게시글 목록 조회 API
      • 게시글 조회 API
      • 댓글 목록 조회 API
    • 로그인 토큰을 전달하지 않은 채로 로그인이 필요한 API를 호출한 경우 "로그인이 필요합니다." 라는 에러 메세지를 response에 포함하기
    • 로그인 토큰을 전달한 채로 로그인 API 또는 회원가입 API를 호출한 경우 "이미 로그인이 되어있습니다."라는 에러 메세지를 response에 포함하기
  5. 댓글 목록 조회 API
    • 로그인 토큰을 전달하지 않아도 댓글 목록 조회가 가능하도록 하기
    • 조회하는 게시글에 작성된 모든 댓글을 목록 형식으로 response에 포함하기
    • 제일 최근 작성된 댓글을 맨 위에 정렬하기
  6. 댓글 작성 API
    • 로그인 토큰을 전달했을 때에만 댓글 작성이 가능하도록 하기
    • 로그인 토큰을 전달하지 않은 채로 댓글 작성란을 누르면 "로그인이 필요한 기능입니다." 라는 에러 메세지를 response에 포함하기
    • 댓글 내용란을 비워둔 채 API를 호출하면 "댓글 내용을 입력해주세요" 라는 에러 메세지를 response에 포함하기
  7. 댓글 수정 API
    • 로그인 토큰에 해당하는 사용자가 작성한 댓글만 수정 가능하도록 하기
    • API를 호출한 경우 기존 댓글의 내용을 새로 입력한 댓글 내용으로 바꾸기
  8. 댓글 삭제 API
    • 로그인 토큰에 해당하는 사용자가 작성한 댓글만 삭제 가능하도록 하기
  9. 회원가입 테스트 코드 작성
    • 회원가입시 구현한 아래 조건을 검사하는 테스트 코드를 작성하기
      • 닉네임은 최소 3자 이상, 알파벳 대소문자(a~z, A~Z), 숫자(0~9)로 이루어져 있어야 합니다.
      • 비밀번호는 최소 4자 이상이며, 닉네임과 같은 값이 포함된 경우 회원가입에 실패합니다.
      • 비밀번호 확인은 비밀번호와 정확하게 일치해야 합니다.
      • 데이터베이스에 존재하는 닉네임을 입력한 채 회원가입 버튼을 누른 경우 "중복된 닉네임입니다." 라는 에러 메세지를 response에 포함하기
    • 테스트 코드 실행 시 실제로는 데이터베이스에 연결되지 않도록 하기
    • 각 조건 별로 2개 이상의 테스트 케이스가 존재하도록 하기

+) 과제를 다 하셨다면?

  1. 내 블로그 글에 좋아요 기능 달기
    • 로그인 토큰을 전달했을 때에만 좋아요 할 수 있게 하기
    • 로그인 토큰에 해당하는 사용자가 좋아요 한 글에 한해서, 좋아요 취소 할 수 있게 하기
    • 게시글 목록 조회시 글의 좋아요 갯수도 같이 표출하기
  2. 내 프로젝트에 swagger 적용해보기
    • swagger란?
      • Open Api Specification(OAS)를 위한 프레임워크 입니다. API들이 가지고 있는 스펙(spec)을 명세, 관리할 수 있으며, 백엔드와 프론트엔드가 협업할 때 사용할 수 있습니다!

2) AWS 배포

  1. RDS 연결
    • MySQL을 이용하기
  2. EC2 배포
    • Ubuntu EC2 를 구매한 뒤, 8080 포트와 80번 포트를 연결하여 포트 번호 없이도 서비스에 접속 가능하게 하기

HangHaeLog API 설계

HangHaeLog 데이터베이스 설계

결과물 링크

프로젝트 후기


ORM(Object Relational Mapping)

ORM이란

  • 객체 지향 프로그래밍의 객체와 관계형 데이터베이스의 데이터를 매핑하는 기술
  • 객체 지향 프로그래밍에서 사용할 수 있는 가상의 객체 지향 데이터베이스를 만들어 프로그래밍 코드와 데이터 연결
  • SQL을 사용하지 않고도 DB의 데이터를 쉽게 객체로 만들어줌

ORM 장점

  • 객체 지향적인 코드로 인해 더 직관적이고 비즈니스 로직에 좀 더 집중할 수 있게 도움
    • 선언문, 할당, 종료 같은 부수적인 코드가 없거나 급격히 줄어듦
    • 각종 객체에 대한 코드를 별도로 작성하기 때문에 코드의 가독성을 올려줌
    • SQL의 절차적이고 순차적인 접근이 아닌 객체지향적인 접근으로 인해 생산성이 증가
  • 재사용 및 유지보수의 편리성 증가
    • ORM은 독립적으로 작성되어있고, 해당 객체들을 재활용 할 수 있음
    • 때문에 모델에서 가공된 데이터를 컨트롤러에 의해 뷰와 합쳐지는 형태로 디자인 패턴을 견고하게 다지는데 유리
    • 매핑정보가 명확하여, ERD를 보는 것에 대한 의존도를 낮출 수 있음
  • DBMS에 대한 종속성이 줄어듦
    • 대부분 ORM 솔루션은 DB에 종속적이지 않음
    • 종속적이지 않다는것은 구현 방법뿐만 아니라 많은 솔루션에서 자료형 타입까지 유효
    • 프로그래머는 Object에 집중함으로 극단적으로 DBMS를 교체하는 거대한 작업에도 비교적 적은 리스크와 시간이 소요됨
    • 또한 자바에서 가공할경우 equals, hashCode의 오버라이드 같은 자바의 기능을 이용할 수 있고, 간결하고 빠른 가공이 가능

ORM 단점

  • 완벽한 ORM 으로만 서비스를 구현하기가 어려움
    • 사용하기는 편하지만 설계는 매우 신중하게 해야함
    • 프로젝트의 복잡성이 커질경우 난이도 또한 올라갈 수 있음
    • 잘못 구현된 경우에 속도 저하 및 심각할 경우 일관성이 무너지는 문제점이 생길 수 있음
    • 일부 자주 사용되는 대형 쿼리는 속도를 위해 SP를 쓰는등 별도의 튜닝이 필요한 경우가 있음
    • DBMS의 고유 기능을 이용하기 어려움
      (하지만 이건 단점으로만 볼 수 없음 : 특정 DBMS의 고유기능을 이용하면 이식성이 저하됨)
  • 프로시저가 많은 시스템에선 ORM의 객체 지향적인 장점을 활용하기 어려움
    • 이미 프로시저가 많은 시스템에선 다시 객체로 바꿔야하며, 그 과정에서 생산성 저하나 리스크가 많이 발생할 수 있음

SQL(Structured Query Language)

SQL이란

  • 관계형 데이터베이스 관리 시스템(RDBMS)의 데이터를 관리 및 처리하기 위해 설계된 특수목적의 프로그래밍 언어
  • 관계형 데이터베이스 관리 시스템에서 자료의 검색과 관리, 데이터베이스 스키마 생성과 수정, 데이터베이스 객체 접근 조정 관리를 위해 고안됨
  • MySQL, MariaDB, MSSQL, 오라클 등의 데이터베이스 관련 프로그램들이 SQL을 표준으로 채택

SQL 문법 종류

DDL(Data Definition Language, 데이터 정의 언어)

  • 각 릴레이션을 정의하기 위해 사용하는 언어
  • ex) CREATE, ALTER, DROP

DML(Data Manipulation Language, 데이터 조작 언어)

  • 데이터를 추가/수정/삭제하기 위한, 즉 데이터 관리를 위한 언어
  • ex) SELECT, INSERT, UPDATE, DELETE

DCL(Data Control Language, 데이터 제어 언어)

  • 사용자 관리 및 사용자별로 릴레이션 또는 데이터를 관리하고 접근하는 권한을 다루기 위한 언어
  • ex) GRANT, REVOKE

SQL 언어적 특성

  1. SQL은 대소문자를 가리지 않음
    • 단, 서버 환경이나 DBMS 종류에 따라 데이터베이스 또는 필드명에 대해 대소문자를 구분하기도 함
  2. SQL 명령은 반드시 세미콜론(;)으로 끝나야 함
  3. 고유의 값은 따옴표("")로 감싸줌
    • ex) SELECT * FROM EMP WHERE NAME = 'James';
  4. SQL에서 객체를 나타낼 때는 백틱(``)으로 감싸줌
    • ex) SELECT `COST`, `TYPE` FROM `INVOICE`;
  5. 주석은 일종의 도움말로, 주석처리된 문장은 프로그램에서 동작하지 않음
    • 한 줄 주석은 문장 앞에 --를 붙여서 사용
      • ex) -- SELECT * FROM EMP;
    • 여러 줄 주석은 /* */로 감싸줌
      • ex) /* SELECT * FROM EMP WHERE EMPID = (SELECT * FROM EMP WHERE NAME = '홍길동'; */

MVC(Model-View-Controller)

MVC패턴이란

  • 애플리케이션 개발을 세 부분의 레이어로 구분해 처리하는 개발방법론

모델(Model)

  • 애플리케이션이 무엇을 할 것인지 정의
  • 내부 비즈니스 로직을 처리하기 위한 역할
  • 데이터 저장소(DB)와 연동하여 사용자가 입력한 데이터나 사용자에게 출력할 데이터를 다룸
  • 여러 개의 데이터 변경 작업을 하나의 작업으로 묶은 트랜잭션을 다루는 일도 함
  • 다른 컴포넌트들에 대해 알지 못하며 자기 자신이 무엇을 수행하는지만 알고 있음

뷰(View)

  • 사용자에게 결과를 화면(UI)로 보내줌
  • 화면에 무엇을 보여주기 위한 역할
  • Model이 처리한 데이터나 그 작업 결과를 가지고 사용자에게 출력할 화면을 만듦
  • 다른 컴포넌트들에 대해 알지 못하며 자기 자신이 무엇을 수행하는지만 알고 있음

컨트롤러(Controller)

  • Model과 View 사이에 있는 컴포넌트
  • Model이 데이터를 어떻게 처리할지 알려주는 역할
  • 클라이언트의 요청을 받으면 해당 요청에 대한 실제 업무를 수행하는 Model을 호출
  • 클라이언트가 보낸 데이터가 있는 경우엔 모델을 호출할 때 전달하기 쉽게 적절히 가공하여 전달
  • Model이 업무 수행을 완료하면 그 결과를 가지고 화면을 생성하도록 View에 전달
  • 클라이언트의 요청에 대해 Model과 View를 결정하여 전달하는 일종의 조정자로서의 일을 함
  • 다른 컴포넌트들에 대해 알고있으며 자기 자신 외에 Model과 View가 무엇을 수행하는지 알고 있음

MVC패턴 방식

Model 1

Model 2

MVC패턴 장점

  • 비즈니스 로직과 UI 로직을 분리하여 유지보수를 독립적으로 수행 가능
  • Model과 View가 다른 컴포넌트들에 종속되지 않아 애플리케이션의 확장성, 유연성에 유리
  • 중복 코딩의 문제점 제거

profile
👊천천히, 하지만 꾸준히👊

0개의 댓글