서론

저번주에 세운 목표

• 자료구조 알고리즘 하루에 한문제 이상 풀기(혹은 도전하기) ⭕️
• 스프링 온라인강의 10강까지 듣고 개념 정리 & 실습하기 ⭕️
• TIL/ 오류 기록하기 🚫
  • 공부했던 이론 부분에 대해선 기록했지만 오류, 토이프로젝트 관련 글들은 작성하지 못했다.

이룬것들

• 자료구조 알고리즘 문제 이전에 어렵다고 생각해 풀지 못했던 문제들 도전하고 풀이도 성공함

• 스프링 온라인 강의를 수강하면서 RestAPI 에 대해서 더 자세하게 알게되었고 해당 부분을 실습하기 위해서 기존에 만들어둔 프로젝트를 Rest 규칙에 맞게 수정함

• Validation 부분을 수강하고 나서 실습을 위해 기존에 만들어둔 프로젝트에 비동기 통신으로 검증 오류를 받아와서 실시간으로 뷰에 출력하게끔 구현

• validation 부분을 실습하면서 사용했던 jquery 문법을 이용하여 비동기 통신으로 처리가 가능했던 부분들을 동기식에서 비동기식으로 변경

본론

자료구조 알고리즘 하루에 한문제 이상 풀기 ( 혹은 도전하기)

해당 알고리즘 자료집 추천문제를 풀이했습니다.

제가 풀이했던 문제는 후위표기식, 풍선 터뜨리기, 스택수열, 쇠막대기, 괄호의값 이었는데요

이중에서 하루만에 풀이하지 못해 2일로 나눠서 풀이했던 문제도 포함되어있습니다.

기존에 문제 풀이로 인해서 크게 얻어가는 부분이 있었다기 보다는, 해당 자료구조로 풀어야 하는 문제들이 어느정도 유사한 패턴을 갖고있어

해당 패턴이 익혀진다면 비슷한 난이도의 문제들을 풀때 크게 막히는 부분이 없을것 같다는 생각이 들었습니다.

알고리즘을 풀면서 지능이 높아진다기 보다는 해당 패턴에 대한 해결법이 머릿속에 쌓인다 라고 표현하는게 맞는것 같습니다.

스프링 온라인강의 10강까지 듣고 개념 정리 & 실습하기

기존에 온라인 강의중 본격적인 스프링 강의는 9강 부터였고, 10강까지 수강하기를 목표로 잡고 스터디를 시작했습니다.

그중에 제가 개인적으로 이론을 정리하기 어려웠던 부분인 IoC(제어역전)와 DI(의존성주입),트랙잭션 에 대해서 정리를 했고

IoC는 스프링 컨테이너가 사용자가 직접 객체를 생성하지 않게 하고, 각 객체의 생명 주기를 스프링 컨테이너가 관리하도록 해 사용자의 제어권을 다른 주체에게 넘기는것이 제어역전 이라고 정리하게 되었습니다.

( bean으로 등록된 ArticleService 와 ArticleRepository, HashtagRepository 가 주입이 된 모습입니다. 스프링 컨테이너는 빈으로 등록된 ArticleService 를 직접 관리해 사용자가 객체를 관리할 필요가 없게 도와줍니다. )

DI (의존성 주입)는 말그대로 의존성을 주입시켜주는 것으로 , 스프링의 bean 과 연관관계가 있다는 생각을 했습니다.

예를 든다면 계산기를 사용하기 위해 건전지를 장착해야 한다면, 계산기는 건전지가 없으면 동작하지 않기때문에 계산기에 건전지의 의존성을 주입했다고 할 수 있다 라고 정리 했습니다.

스프링은 싱글톤 패턴으로 빈을 관리하기 때문에, 빈으로 등록된 클래스들은 각각 새로운 객체로 인스턴스화 되어 반환되는게 아닌, 스프링 컨테이너에 빈으로 등록된 객체로 리턴이 된다 라는걸 알게되었습니다.
(알아보는 방법은 반환되는 객체를 출력해보면 값이 같은것을 볼 수 있습니다.)

이렇게 스프링은 결론적으로 더 나은 프로그래밍 환경을 만들어주는 프레임워크 라고 정리하게 되었습니다.

Transaction 같은 경우에는 데이터베이스 관련 용어라고 생각을 했는데요, 데이터가 입력 삭제 수정 조회 등등 되었을때, 각각의 작업 하나하나를 트랜잭션 이라고 불리고, 우리는 안정성을 위해 그 범위를 조절할 수 있고, 그에 대한 작업처리를 통으로 Transaction 으로 칭한다.. 정도로 정리를 했습니다.

AOP같은 경우는 실습이 어려운 파트라 생각이 되어 용어들만 간단하게 정리하고 패스했습니다.

그리고 강의 내용중 Http 테스트, Validation 적용 부분은 직접 제가 실습을 진행할 수 있겠다라는 생각이 들어 개인적으로 적용을 해보았습니다.

Http 테스트 실습/ REST API

강의에 나왔던 내용들은 단순 Http 에 대한 설명과 Http 메소드에 대한 설명이 대부분이었고,

기존에 궁금했던 부분은 RestApi에 대한 부분이었습니다.

[Network] REST란? REST API란? RESTful이란?

REST의 구체적인 개념
HTTP URI(Uniform Resource Identifier)를 통해 자원(Resource)을 명시하고, HTTP Method(POST, GET, PUT, DELETE)를 통해 해당 자원에 대한 CRUD Operation을 적용하는 것을 의미한다.
https://gmlwjd9405.github.io/2018/09/21/rest-and-restful.html

해당 글을 보고 살짝 충격을 받았습니다.
제가 놀이터마냥 개인적으로 만들었던 게시판이 http 메소드의 각각의 역할에 맞지 않게 GET과 POST 가 범벅이된 말그대로 Restful 하지 못하다는 생각이 들었습니다.

거기서도 제가 어겼던 부분들이 있었는데, RestAPI 설계 기본 규칙중 URI 에 http 메소드가 들어가면 안되고, URI에 행위에 대한 동사가 들어가면 안된다는 부분이었습니다.

RESTful이란
RESTful은 일반적으로 REST라는 아키텍처를 구현하는 웹 서비스를 나타내기 위해 사용되는 용어이다.
‘REST API’를 제공하는 웹 서비스를 ‘RESTful’하다고 할 수 있다.
https://gmlwjd9405.github.io/2018/09/21/rest-and-restful.html

-> articleDelete 이지만 GetMapping 어노테이션을 사용한 모습

해당 컨트롤러 메소드처럼 중구난방인 모습이 많았습니다.

마찬가지로 html 태그는 기본적으로 메소드 타입에 PUT과 DELETE 를 제공해주지 않았기때문에, 평소에 배워보고 싶었던 jquery 를 사용해 타임리프가 아닌 jquery 로 요청과 응답을 주고 받도록 방식을 변경했습니다.

그리고 더 나아가 해당 방식을 사용함에 따라 기존의 모든 응답을 뷰로 내보내줘서 무조건 새로고침이 되거나 페이지가 변경되어야지 받아올 수 있던 응답을 json 형태로 받아와서

페이지가 변경되지 않아도 결과를 출력할 수 있는 로직을 구현해보았습니다.

데이터 validation 적용 / 실시간 응답

페이지가 변경되지 않아도 결과를 출력할 수 있어야만 하는 부분이 있었습니다. 개인적으로 어떠한 폼 을 작성할때가 그 경우였는데요,

댓글 작성이라던가 로그인, 회원가입, 글작성 등등 여러가지 어떠한 폼을 작성해 제출해야 하는 부분에서 각각 폼이 원하는 값이 들어오지 않았을떄, 그것을 사용자가 모든 폼을 작성하고 제출했을때 알게된다면, 불편하지 않을까 하는 생각이 들었습니다.

그렇게 스프링 Validation이 적용된 자바빈 형태의 Dto 가 검증 오류를 리턴했을때,

뷰를 받아와서 출력해주는게 아닌 실시간으로 제이쿼리를 이용해서 같이 실습을 진행했습니다.

데이터 검증 비즈니스 검증

강의에서 진행된 내용에 따라

저는 회원가입 양식을 통해 각각의 값을 검증하는 데이터 검증과

각각 값들이 이미 서버상에 존재하여 중복 등록이 될 수 없는지 검증하는 비즈니스 검증 이렇게 두가지 검증을 한 페이지에서 진행했습니다.

데이터 밸리데이션 (자바빈 형태의 데이터 전송용 클래스에서 Validation 관련 어노테이션을 사용한 모습입니다.)

비즈니스 밸리데이션 (비즈니스 로직으로 각각 데이터에 직접 접근해 검증해 불리언 타입으로 리턴해줍니다.)

이렇게 원하는 아이디를 입력하고, 다음 폼으로 이동했을때

해당 입력값을 json 형태로 전송해 비즈니스 로직에서 검증을 진행한후에 중복값일경우 true, 아닐경우 false 로 전송해 실시간으로 검증을 진행합니다.

데이터 검증같은 경우에는 @valid 어노테이션을 해당 폼 앞에 사용하고, 검증을 위한 데이터 바로 뒷 매개값으로 BindingResult 를 전달했을때 자동으로 필드 에러를 리턴해줍니다.

필드 에러 출력을 위해서 따로 유틸리티 클래스를 생성해 bindingResult 의 FieldError 들만을 뽑아와서 출력하게끔 메소드를 선언해줘 스프링의 기능을 백분 활용해보았습니다.

이렇게 해당 메소드는 필드를 key 로, 에러 메세지를 value 로 Map 구조로 리턴해줍니다.

그거를 json 형태로 제출시에 받아와서 출력이 됩니다.

이렇게 해당 필드에서 오류가 발생하면 각각 어노테이션에 정의해준 메세지가 출력이되게 됩니다.

비동기 통신 실습을 위한 댓글 출력/게시글 추천 로직 변경

기존에 댓글을 등록할시에 json 형태로 목록을 가져오면 그것을 토대로 댓글을 출력하는게 아닌 새로고침시에 뷰를 반환하는 형태로 짜여져있었던 구조를

실시간 검증을 통해 배웠던 것들로 응용하여 댓글출력또한 새로고침이 없이 등록했을때 마찬가지로 댓글을 새로 갖고오도록해 반환된 json 으로 댓글을 출력하도록 변경했습니다.

해당 부분은 따로 글로 업로드할 예정입니다.

결론

이번주는 크게 스프링에대한 기본 개념을 한번 더 다지고 , 그것을 단순히 읽기만 하고 넘어가는게 아닌 직접 적용해봄으로써 여러가지 지식을 갖고가는 한 주였습니다.

개인적으로 진짜 강의에서 가르쳐준 내용보다 좀 더 나아가 삽질을 하지 않았나 싶기도 하지민, 절대로 알아봤자 쓸모없는 지식이 아니기때문에 가르쳐주신 내용들을 잘 활용했다 생각합니다.