항해를 하게 된 배경

• 나는 일단 동아방송예술대학을 다니고 있는 3학년(현재는 휴학중) 뉴미디어콘텐츠학과 학생이였다. 내가 가게된 계기를 말하려면 나의 상황을 설명하는 게 필수적일 거라고 생각이 된다. 우리 학과는 뉴미디어(웹, 앱 등)관련된 기획, 디자인, 개발을 배우는 학과이다. 문제는 생각 보다 개발 전공과목에 한 해 깊이가 얕은 편이다. 그래서 다른 학교로의 편입을 고민하던 중, 교수님과 상담을 통해 항해를 알게 되어 들어 오게 되었다. [여기서 ㅡㅡ 내 블로그 이름 탄생! 애매한 학과의 개발 하는 학생이라고 생각이 되서 이상한 나라의 개발하는 예대생]

개발을 하게된 이유

• 위에서 말한 것과 같이, 난 예대생인데.. 개발이 전공과목이다. 그래서 1학년때는 html+css+javascript, node.js 2학년때는 unity, DB(mysql, sqlite), java, 자료구조 배웠다. 노드를 배우면서 함수를 만들고 내가 원하는 값으로 만들어가는 과정이 재미 있었고 java를 배우면서 객체 지향언어가 생각 보다 나랑 잘 맞을 지도? 라고 생각 하면서 지냈던것 같다. 그러면서 내가 배운 과목들을 가지고 활용하면서 사회 생활을 하고 싶다고 생각했던 1, 2학년 시절인것 같다. [나름에 이유가 될지는 모르겠지만]

여러 부트캠프들 중 항해99를 선택한 이유

• 다른 이유보다 3가지 정도를 뽑을 수 있다.

1. 4개월 이라는 기간 : 생각보다 다른 캠프들은 6개월이 기본이다. 난 6개월 뒤면 학교로 복귀를 해야하는 시간이 3개월이 안되는 시간이 남기때문에 기간적인 부분에서 메리트로 다가왔다. (학교로 복귀하면 내가 한 프로젝트나 공부 한게 좋은 밑 바탕이겠지만 더 갈고 닦을 수 없기 때문에 가급적이면 취직이 목표였다.)
2. 온라인 공부 환경: 오프라인도 좋지만 온라인도 상관없었지만, 그나마 내가 편하고 좋은 환경에서 할 수 있다는 건 엄청난 메리트 였다.
3. 12시간의 집중시간: 일단 강제로 공부를 할 수 있는 환경이면 좋겠다 라고 생각했는데 그렇게 안하면 안되는 상황이 만들어 져서 12시간동안 코드에 대해서 열심히 공부 하게 하는 환경이였다고 생각한다.

ps. 이뿐만 아니라 사실, 틈틈히 와서 봐주시는 기술 매니저 분들이 진짜로 내가 생각 하지 못하는 부분들을 잡아 주시는 것들을 보면서 여기 오길 잘했네 싶은 생각을 많이 했던 것 같다.

항해99에서 실제로 좋았던 부분

• 실제로 .. 좋았다 .. 많은 부분이 있지만 6주 동안 마지막 프로젝트를 하면서 큰 기업에서 작업을 하시는 개발자분들이 오셔서 피드백을 해주시고 에러 또는 N+1문제를 같이 고민하면서 해결 할 수 있었다는 부분이 좋았다고 생각이 된다. 뭐 위에 선택한 부분에서 이미 좋았던 부분이 많이 드러나서 간단하게 쓰고 넘겨야지

수료 소감 및 항해99를 고민 중인 분께 한마디

• 수료하고 2주만에 작은 회사지만 취직을 하고 다니는 중이다. 요즘 나는, 많이 바쁘고 어렵고 가끔은 여기저기 팀장님과 팀원분들께 조언을 구해야 하는 갓태어난 기린 같은 나지만 그래도 항해를 수료 했기때문에 이정도라도 하는 게 아닐까 라는 생각을 한다.

• 사람마다 상황이 달라, 꼭 항해를 들어 오라는 말을 하지는 못하지만 그래도 내가 이미 개발을 경험했고 더 성장해서 나아가고자 한다면 항해99를 한번 고민해 보라는 조언을 하고 싶다.

• *시간 복잡도란 *
  • 특정 크기의 입력을 기준으로 할 때 필요한 연산의 횟수를 나타냅니다. 시간 복잡도에는 빅오 표기법이라는 복잡도를 나타내는 점근 표기법 중 가장 많이 사용되는 표기법을 사용합니다.
    • Big O 표기법(Big O Notation)이란? Big O란 연산 횟수의 함수 T(n) 의 최고차항의 차수에 O를 씌운 표기법이다. 아래와 같이 표기하면 된다.빅오의 순서는 아래와 같으며, 커질 수록 연산 횟수가 더 많다는 뜻이며, 연산에 더 오랜 시간이 걸린다는 뜻이다. 화공과에서 수학을 배울 때 배우던 내용과 비슷하다.

• 공간 복잡도는
  • 프로그램 실행과 완료에 얼마나 많은 공간(메모리)가 필요한지를 나타냅니다. 알고리즘을 실행시키기 위해 필요한 공간, 고정 공간과 가변 공간이 있습니다.

일이 진행되는 순서대로 프로그래밍하는 방법

• 장점 코드의 가독성이 좋음. 컴퓨터의 처리구조와 비슷해 실행 속도가 빠름.

• 단점 각각의 코드가 순서에 민감하게 연결 되어있어, 유지보수 및 분석이 어려움.

  객체지향 프로그래밍? (Object Oriented Programming)

  모든 데이터를 객체(Object)로 취급하고,객체가 처리 요청을 받았을 때, 객체 내부에 있는 기능을 사용해 처리하는 방법이다. 서로 연관되어있는 함수와 변수들을 객체라는 것으로 그룹화 한다. 그 객체에 들어있는 함수들을 호출해서 다른 함수들과 분리/구분해줌.

4가지 특징존재한다.

1. 추상화 : 공통적인 속성이나 기능을 묶어서 이름을 붙이는 것
2. 캡슐화 : 데이터를 은닉하고 데이터 기능을 노출시키지 않음.
3. 상속성 : 상위 부모 객체의 속성과 특징을 하위 객체가 물려 받는 것.(만약 어떠한 객체가 이미 존재하는 객체의 특성을 가지고 있다면, 기존 객체의 특성을 상속시켜 만들 수 있음.)
4. 다형성 : 같은 함수가 있어도 매개변수에 따라 각자 다른 일을 하는 것

• 장점 코드의 재사용이 가능.(확장, 유지보수에 용이!) 분석과 설계의 전환이 쉬움.

• 단점 처리 속도가 상대적으로 다소 느림. 설계에 많은 시간이 소요됨.

• 객체지향 프로그래밍 언어: 자바

  함수형 프로그래밍

  "순수 함수"를 사용해, 상태를 제어하기보단, 빨리 처리하는데 초점을 둔 방법 실행 순서를 지정할 필요가 없기 때문에 비절차형 언어라고도 함!

순수 함수란? 동일한 입력값을 넣었을 때 항상 동일한 리턴값을 반환하며 외부에 영향을 받지 않는 함수를 의미한다. 외부에 영향을 받지않는다. 함수의 실행이 프로그램에 영향을 주지 않는다. 비상태 불변성 유지한다. -> 여러가지 동시다발적인 멀티쓰레딩 환경에서도 안정적으로 동작할 수 있다고 한다.

예제 코드

// 순수 함수
  function func(a, b) {
            return a + b; // 인자로 들어온 값만 참조해, 리턴값을 생성
  }

  // 비순수 함수
  function func(a, b) {
            return a + b + c; // 외부 요인(c)에 따라 리턴값이 변경됨
  }

• 장점 함수의 동작부가 간결해지기 때문에, 객체지향 프로그래밍에 비해 코드 이해도와 가독성이 좋아짐. 테스트가 쉬움.

• 단점 외부 데이터 혹은 내부 데이터의 상태를 조작할 수 없음.

스프링 컨테이너는 스프링 프레임워크의 핵심 컴포넌트이다. 스프링 컨테이너는 자바 객체의 생명 주기를 관리하며, 생성된 자바 객체들에게 추가적인 기능을 제공한다. 스프링에서는 자바 객체를 빈(Bean)이라 한다.

즉, 스프링 컨테이너는 내부에 존재하는 빈의 생명주기를 관리(빈의 생성, 관리, 제거 등)하며, 생성된 빈에게 추가적인 기능을 제공하는 것이다. 스프링 컨테이너는 XML, 어노테이션 기반의 자바 설정 클래스로 만들 수 있다. 스프링 부트(Spring Boot)를 사용하기 이전에는 xml을 통해 직접적으로 설정해 주어야 했지만, 스프링 부트가 등장하면서 대부분 사용하지 않게 되었다.

스프링 컨테이너의 종류

BeanFactory

• 빈 팩토리(BeanFactory)는 스프링 컨테이너의 최상위 인터페이스이다.
• BeanFactory는 빈을 등록, 생성, 조회 등의 빈을 관리하는 역할을 하며, getBean() 메서드를 통해 빈을 인스턴스화 할 수 있다.
• @Bean 어노테이션이 붙은 메서드의 이름을 스프링 빈의 이름으로 사용하여 빈 등록을 한다.

ApplicationContext

• 애플리케이션 컨텍스트(ApplicationContext)는 BeanFactory의 기능을 상속받아 제공한다. 따라서, 빈을 관리하고 검색하는 기능을 BeanFactory가 제공하고, 그 외의 부가 기능을 제공한다.

• 부가 기능 MessageSource : 메시지 다국화를 위한 인터페이스이다. EnvironmentCapable : 개발, 운영, 환경변수 등으로 나누어 처리하고, 애플리케이션 구동 시 필요한 정보들을 관리하기 위한 인터페이스이다. ApplicationEventPublisher : 이벤트 관련 기능을 제공하는 인터페이스이다. ResourceLoader : 파일, 클래스 패스, 외부 등 리소스를 편리하게 조회한다.

  스프링 컨테이너의 기능

  

• 스프링 컨테이너는 빈(Bean)의 인스턴스화, 구성, 전체 생명 주기 및 제거까지 관리한다.*

• 컨테이너는 개발자가 정의한 빈을 객체로 만들어 관리하고 개발자가 필요로 할 때 제공한다.

스프링 컨테이너를 통해 원하는 만큼 많은 객체를 가질 수 있다. 의존성 주입(DI)을 통해 애플리케이션의 컴포넌트를 관리할 수 있다. ** **스프링 컨테이너는 서로 다른 빈을 연결하여 애플리케이션 빈을 연결하는 역할을 한다.

• 개발자는 모듈 간에 의존 및 결합으로 인해 발생하는 문제로부터 자유로울 수 있다.
• 메서드가 언제 어디서 호출되어야 하는지, 메서드를 호출하기 위해 필요한 매개 변수를 준비해서 전달하지 않는다.

| Array | LinkedList |
| --- | --- |
| 연속된 메모리 공간에 존재함. | 메모리 상에서 떨어져 있는 데이터들이 앞과 뒤의 데이터를 기억하는 형태로 존재함. |
| 데이터를 조회할 때 시간 : O(1) | 데이터를 조회할 때 시간 : O(N) |
| 컴파일 과정에서 메모리가 할당되는 정적 메모리 할당 | 런타임 환경에서 메모리가 할당되는 동적 메모리 할당 |
| 정적인 데이터를 저장하고 관리할 때 적합함. | 동적인 데이터를 저장하고 관리하는데 적합함. |
| Stack 영역에 메모리 할당 | Heap 영역에 메모리 할당 |

• 맵 (Map) : key - value로 데이터를 저장하는 자료구조, HashMap, TreeMap, LinkedHashMap 등

  • HashMap

    • key - value를 하나의 데이터(entry)로 저장한다.
    • hashcode를 사용하기 때문에 예측할 수 없는 순서로 저장된다. (TreeMap과 차이점)
    • key는 중복되지 않지만 값은 중복이 될 수 있다. 기존에 저장된 key로 값을 저장하면 기존 값은 없어지고 새로운 값이 저장된다.
    • hashing을 사용하기 때문에 많은 양의 데이터를 검색할 때 성능이 좋다.
    • 해시 함수를 통해 매핑된 해시를 Index로 활용하기 때문에 데이터에 대한 검색, 삽입, 제거 연산의 시간 복잡도가 O(1)이라는 확실한 장점이 있다.

  • TreeMap

    • key 값에 따라서 자동으로 Sort가 된다.
    • 숫자 타입일 경우에는 값으로, 문자열 타입일 경우에는 유니코드로 오름차순 정렬한다.
    • HashMap과는 다르게 key 값으로 null을 허용하지 않는다.
    • 데이터를 저장할 때 즉시 정렬하기 때문에 추가나 삭제가 HashMap 보다 오래 걸린다.
    • 셋 (Set) : 순서가 없는 데이터를 중복 없이 저장하는 자료구조, HashSet, TreeSet 등
    • 스택 (Stack) : 후입선출 구조를 갖는 자료구조, push()와 pop() 메소드를 이용하여 데이터를 추가하고 삭제함(FILO : First In Last Out)
    • 큐 (Queue) : 선입선출 구조를 갖는 자료구조, Enqueue(), Dequeue() 메소드를 이용하여 데이터를 추가하고 제거함(FIFO: First In First Out)
    • 덱 (Deque) : 양쪽 끝에서 삽입과 삭제가 모두 가능한 자료구조, LinkedList 등
      • 큐의 자료구조형을 양방향에 가능 하게 만든 자료구조라고 생각 하면 편하다.

• 비선형

  • 트리 (Tree) : 계층적 구조를 갖는 자료구조, 이진트리, 이진탐색트리, AVL 트리, 레드 블랙 트리 등

    • 이진 트리 : 자식 노드가 최대 2개인 노드들로 구성된 트리

      • 전위 순회, 중위 순회, 후위 순회를 통해 탐색할 수 있다. (https://code-lab1.tistory.com/9 참고)
      • 이진 탐색 트리 : 이진 탐색 + LinkedList를 결합한 이진 트리
        • 트리의 높이가 h라면 O(h)의 복잡도를 가지게 된다.
        • 이진 트리보다 탐색이 빠르다.
        • 트리 안에 찾고자 하는 값이 없더라도 최대 h번의 연산 및 탐색이 진행된다.

  ---

  • 그래프 : 노드와 노드 간을 연결하는 간선으로 구성된 자료구조, 이를 통해 연결된 노드 간의 관계를 표현할 수 있는 자료구조

  • 트리와 그래프의 차이점

    |  | 트리 | 그래프 |
    | --- | --- | --- |
    | 정의 | 그래프의 한 종류, 방향성이 있는 비순환 그래프 | 노드와 노드를 연결하는 간선으로 구성된 자료구조 |
    | 방향성 | 방향 그래프만 존재 | 방향, 무방향 모두 존재 |
    | 사이클 | 비순환 그래프만 존재 | 순환, 비순환 모두 존재.
    노드 한개의 자체 순환도 가능. |
    | 루트 노드 | 한 개의 루트 노드만이 존재 | 루트 노드의 개념이 없음 |
    | 부모 - 자식 | 루트 노드를 제외한 노드는 1개의 부모 노드만을 가짐 | 부모 - 자식 개념이 없음 |
    | 모델 | 계층 모델 | 네트워크 모델 |
    | 순회 | DFS, BFS 방식의 전위, 중위, 후위 순회 | DFS, BFS |
    | 간선의 수 | N개의 노드를 가진 트리는 항상 N - 1개의 간선을 가짐 | 간선의 개수는 자유, 없을 수도 있음 |
    | 경로 | 임의의 두 노드 간의 경로는 유일 |  |
    | 예시 및 종류 | 이진 트리, 이진 탐색 트리, 레드 블랙 트리, 이진 힙 | 지도, 지하철 노선도의 최단 경로, 전기 회로의 소자들, 선수 과목 |

제네릭을 알기전에 일단은 ArrayList를 잠깐 보자.

// ArrayList
ArrayList<String> arrList = new ArrayList<String>();

안에 보면 ArrayList에 어떤 타입의 데이터를 넣을 건지 정해준다. 이 <>를 제네릭(Generics)이라 하는데, 이 <>안에 어떠한 타입을 선언해주어 해당 ArrayList, List 등이 사용할 객체의 타입을 지정해준다는 뜻이다. 이렇게 되면 내가 사용하고 싶은 데이터 타입만 사용할 수 있게 해주는 효과가 있다.

그럼 Generics의 장점은 무엇일까?

• 1. 타입의 안정성 : 의도하지 않은 타입의 객체가 저장되는 것을 막고, 다른 타입의 객체로 인한 타입 형태가 맞지 않아 발생하는 문제를 없애준다.
• 2. 불필요한 형변환을 줄여 코드의 간결함 : 타입을 미리 명시함으로써 다른 타입의 객체가 저장되지 않아 객체를 꺼내 사용할 시 형변환을 통한 타입을 맞출 필요가 없어 코드를 간결하게 줄일 수 있다.

Collections 클래스

• 컬렉션에 대해 연산 수행, 결과로 컬렉션 return 한다.
• 모든 메소드는 static 타입이다. 주요 메소드는 아래의 그림으로 확인 할 수 있다.
• Collections class 에서 Generics를 사용하는 이유는 명확하게 알기 힘들다.(조금더 알면 수정 하고자 한다.)

• jpa를 공부하면서 빠질 수 없는 내용이라고 한다.
• *엔티티를 영구 저장하는 환경을 의미 한다. *
• application과 DB 사이에서 객체를 보관하는 가상의 DB 같은 역할을 한다.
• 서비스 각각마다 하나의 EntityManager Factory가 존재하며 EntityManager Factory에서 DB에 접근하는 트렌젝션이 생길 때마다 쓰레드 별로 EntityManager를 생성하여 영속성 컨텍스트에 접근한다.
• 영속성 컨텍스트는 EntityManager를 생성할 때 만들어지며 EntityManager를 통해 영속성 컨텍스트에 접근하고 관리한다.

그럼 계속 언급되는 EntityManager는 무엇일까?

EntityManager

• EntityManager는 영속성 컨텍스트 내에서 Entity들을 관리 한다.
• EntityManager는 JPA에서 제공하는 interface로 spring bean으로 등록되어 있어 Autowired로 사용할 수 있다.

  @Autowired
  private EntityManager entityManager;

• Query Method, Simple JPA repository는 직접적으로 entityManager를 사용하지 않도록 한번 더 감싸준 것이다. *결국 우리는 모르는 사이에 Jpa 영속성 컨텍스트를 쓰고 있었다는 것!!
• 기존의 Spring jpa 에서 제공하는 것 이외의 작업이 필요하다면 EntityManager를 이용해서 직접 처리한다.
• EntityManager는 Entity Cache를 가지고 있다.

  Entity의 생명주기

  모르는 사실중에, Entity도 생명주기가 있다는 이야기 였다. 정말 나는 모르고 작업을 많이 했다는 생각이 드는 부분이였다.

  Entity의 생명주기는 각각 비영속, 준영속, 영속, 삭제로 나눌 수 있다. 일단은 하나하나 알아 보자.

비영속(new/transient)

• 영속성 컨텍스트와 전혀 관계가 없는 상태이다.

• 엔티티 객체를 생성하였지만 아직 영속성 컨텍스트에 저장하지 않은 상태를 의미한다.

• 말그대로 영속성 컨텍스트과 비영속, 즉 관계가 없는 상태라고 생각 하면 될 것 같다.

  //객체만 생성한 비영속상태 
     User user = new User();

  영속(managed)

• 영속성 컨텍스트에 저장된 상태를 의미 한다.

• 엔티티가 영속성 컨텍스트에 의해 관리된다.

• 영속 상태가 되었다고 바로 DB에 값이 저장되지 않고 트렌젝션의 커밋 시점에 영속성 컨텍스트에 있는 정보들을 DB에 쿼리로 날리게 된다.(Entity Manager에서 관리 하다가 DB로 넘어가는 이미지를 생각하면 좋을 것 같다.)

  @Autowired
  private EntityManager entityManager;
  // Class내에 Autowired로 EntityManager추가
  
    //객체만 생성한 비영속상태 
    User user = new User();
  
    // 객체를 저장한 영속상태
    entityManager.persist(user);

  준영속(detached)

• 영속성 컨텍스트에 저장되었다가 분리된 상태를 의미한다.

  // 영속 -> 준영속
    // user엔티티를 영속성 컨텍스트에서 분리하면 준영속 상태가 된다.
    entityManager.detach(user);
    // 영속성 콘텍스트를 비우면 관리되고 있던 엔티티들은 준영속 상태가 된다. (대기 상태에 있는 변경 데이터들도 삭제)
    entityManager.clear();
    // 영속성 콘텍스트를 종료해도 관리되던 엔티티들은 준영속 상태가 된다.
       entityManager.close();
  
    // 준영속 -> 영속 
    // detach를 하여 준영속상태에 빠진 entity를 merge를 하면 다시 영속 상태가 된다.
    entityManager.merge(user); 

  그럼 준영속 상태의 특징은 무엇일까?

• 1차 캐시, 쓰기 지연, 변경 감지, 지연 로딩을 포함한 영속성 컨텍스트가 제공하는 어떠한 기능도 동작하지 않는다.

삭제(removed)

• 영속성 컨텍스트와 DB에서 해당 엔티티를 삭제하여 삭제된 상태이다.

  // user엔티티를 영속성 컨텍스트와 DB에서 삭제
    entityManager.remove(user);

일단 예외 처리에 대해서 이야기를 하기전에 MVC가 뭔지 다시 생각하고 가보자

MVC 란?

MVC (모델-뷰-컨트롤러) 는 사용자 인터페이스, 데이터 및 논리 제어를 구현하는데 널리 사용되는 소프트웨어 디자인 패턴입니다. 소프트웨어의 비즈니스 로직과 화면을 구분하는데 중점을 두고 있습니다. 이러한 "관심사 분리" 는 더나은 업무의 분리와 향상된 관리를 제공합니다. MVC 에 기반을 둔 몇 가지 다른 디자인 패턴으로 MVVM (모델-뷰-뷰모델), MVP (모델-뷰-프리젠터), MVW (모델-뷰-왓에버) 가 있습니다.

그럼 MVC 패턴인데 스프링에서는 어떤 구조로 돌아 갈까?

스프링 MVC 수행흐름

일단 우리는 간단한 구성을 보고자 하는 거니까 이 그림만 보고 알고 가자!

Spring에서의 예외처리 방법

컨트롤러단에서 처리하는 방법 Controller Level : @ExceptionHandler 전역 처리 방법 Global Level : @ControllerAdvice 메서드단위 처리 Method Level : try/catch 또는 throws

Controller 레벨에서의 예외처리 (@ExceptionHandler)

@ExceptionalHandler 어노테이션 사용하여 같은 컨트롤러의 요청 처리 메소드에 의해 발생하는 예외처리를 구체화 할 수 있다. 위 컨트롤러 내에서 발생하는 TestException에 대해 예외 발생시 ControllerExceptionHandler메소드에서 처리된다. Controller메소드 내의 하위 서비스에서 예외가 발생하더라도 중간에 처리하지 않으면 Controller단까지 예외가 던져지므로 @ExceptionHandler가 예외를 처리하게 된다.

@RestController
public class TestController {

    private final Logger logger = LoggerFactory.getLogger(UserController.class);

    // 예외 핸들러
    @ExceptionHandler(value = TestException.class)
    public String controllerExceptionHandler(Exception e) {
        logger.error(e.getMessage());
        return "/error/404";
    }

    @GetMapping("hello1")
    public String hello1() {
        throw new TestException("hello1 에러 "); // 강제로 예외 발생
    }

    @GetMapping("hello2")
    public String hello2() {
        throw new TestException("hello2 에러 "); // 강제로 예외 발생
    }
}

전역 예외 처리 방법 (@ControllerAdvice)

예외를 컨트롤러가 아닌 전체 어플리케이션에 적용할 수 있게 만들어 준다. 아래 어노테이션을 사용하면 된다. @ControllerAdvice

• 모든 Controller에서 발생하는 예외를 처리할 수 있게 해준다.
• DispatcherServlet에서 발생하는 예외를 전역적으로 처리해준다.
• Controller 의 @ExceptionHandler와 Controlleradvice의 @ExceptionHandler가 겹치는경우, @ExceptionHandler가 우선적으로 처리된다.

*오늘 발표중 알게된 이야기 Filter에서의 예외 스프링의 처리과정중 예외가 발생하는 부분은 크게 두가지로 나눴을 때 Dispatcher Servlet내에서 발생하는 예외 Dispatcher Servlet 전의 서블릿(Filter) 에서 발생하는 예외가 존재한다. Filter에서 예외가 발생한 경우 Web Application레벨에서 처리를 해주어야한다.

object-oriented programming(OOP)의 약자로 객체의 관점에서 프로그래밍하는 것을 의미한다.

• 프로그래밍 세계의 철학으로 사람이 이해하는 방법을 흉내한 방법론 입니다.
• 객체는 유기적으로 연결하여 프로그래밍을 합니다.

  Rest API / RestFul API

REST(REpresentational State Transfer) : "REpresentational State Transfer" 의 약자, 자원을 이름(자원의 표현)으로 구분해 해당 자원의 상태(정보)를 주고 받는 모든 것을 의미합니다. 즉, `자원(resource)의 표현(representation)에 의한 상태 전달`!

• 자원 : 해당 소프트웨어가 관리하는 모든 것 (문서, 그림, 데이터, 해당 소프트 웨어 자체 등)
• 표현 : 그 자원을 표현하기 위한 이름 (DB의 학생 정보가 자원이면, ‘students’를 자원의 표현으로 정함)
• 상태 전달 : 데이터가 요청되는 시점에 자원의 상태를 전달한다. (JSON 혹은 XML을 통해 데이터를 주고 받는 것이 일반적)

REST는 기본적으로 웹의 기존 기술과 HTTP 프로토콜을 그대로 활용하기 때문에

웹의 장점을 최대한 활용할 수 있는 아키텍처 스타일입니다.

REST는 네트워크 상에서 Client와 Server 사이의 통신 방식 중 하나입니다.

REST의 개념 어떤 자원에 대해 CRUD 연산을 수행하기 위해 URI(Resource)로 GET, POST 등의 방식(Method)을 사용하여 요청을 보내며, 요청을 위한 자원은 특정한 형태(Representation of Resource)로 표현됩니다.

여기서 잠깐! URL과 URI의 차이점은?

URL은 Uniform Resource Locator로 인터넷 상 자원의 위치를 의미합니다. 반면 URI는 Uniform Resource Identifier로 인터넷 상의 자원을 식별하기 위한 문자열의 구성으로, URI는 URL을 포함하게 됩니다. URI가 URL보다 포괄적인 범위라고 할 수 있습니다.

REST의 구성요소

1. 자원(Resource) - URI

• 모든 자원에는 고유한 ID가 존재하며 이 자원은 Server에 존재합니다.
• 자원을 구별하는 ID는 HTTP URI입니다.
• Client는 URI를 이용해 자원을 지정하고 해당 자원의 상태(정보)에 대한 조작을 Server에 요청합니다.

1. 행위(Verb) - Method

• HTTP 프로토콜의 Method를 사용합니다.
• HTTP 프로토콜은 다음과 같습니다.

REST API

• REST의 특징을 기반으로 서비스 API를 구현한 것입니다.

REST API 특징

• 가장 큰 특징은 각 요청이 어떤 동작이나 정보를 위한 것인지를 그 요청의 모습 자체로 추론이 가능하다는 것입니다.

REST API의 설계 규칙

1. URI는 명사를 사용(리소스명은 동사가 아닌 명사를 사용해야 합니다.)

• 예) 다음과 같은 동사는 안됨!!
  • /updateUser
  • /deleteUser

1. 슬래시( / )로 계층 관계를 표현합니다.
2. URI 마지막 문자로 슬래시 ( / )를 포함하지 않습니다.
3. 밑줄( _ )을 사용하지 않고, 하이픈( - )을 사용합니다.
4. URI는 소문자로만 구성합니다.
5. HTTP 응답 상태 코드를 사용합니다.

• 클라이언트는 해당 요청에 대한 실패, 처리 완료, 잘못된 요청 등에 대한 피드백을 받아야 합니다.

1. 파일확장자는 URI에 포함하지 않습니다. 예) 다음 예시처럼 사용하면 안됨!
   • http://hanghae99.gmail.com/restapi/10/photo.jpg

REST API와 RESTful API의 차이

RESTful API :

REST의 설계 규칙을 잘 지켜서 설계된 API를 RESTful한 API 라고 합니다.

즉, REST의 원리를 잘 따르는 시스템을 RESTful이란 용어로 지칭됩니다.

• 첫 번째,

  URI는 정보의 자원을 표현해야 한다.

• 두 번째,

  자원에 대한 행위는 HTTP Method(GET, POST, PUT, PATCH, DELETE)로 표현한다.

  • 행위(Method)는 URI에 포함하지 않는다.

중요하니까 한 번 더~ REST API는 한마디로 URI는 정보의 자원만 표현해야 하며, 자원의 행위는 HTTP Method에 명시한다는 것이다!!!

별생각 안했던, 실전 프로젝트가 다음주면 온다고 한다. 나랑 같이 리더 /부리더로 하는 오빠와 이야기를 나누어 봐야 겠다. 일단은 간단하게 이야기 나눈 결과로, wed socket과 RTC를 구현 해보자고 이야기 해 보았다 그러면 타겟층을 잘 선택하고 진행하면 좋을 것 같다고 생각 했다.

나의 결심

그나마 내가 작업을 하면서, 나만의 메리트를 보여줄 수 있는 것이 무엇일까 생각 했다. 프론트, 백 모두에게 내가 어느정도 웹 기획에 대해서 이해하고 있다는 느낌을 주는 것이 어떨까라는 생각을 하였다. 첫주에 만드는 기획안에 간단하지만 이해 하고 있다는 인상을 주려고 한다.

간단하게 해야할 일들

생각을 해보면 처음에 해야 할 일들을 정리 해봐야 겠다.

1. 레퍼런스 찾기
2. 타겟층 정리, 해당 타겟에 맞춘 페르소나 모델과 고객여정지도 만들기
3. SWOT분석 및 전략선택
4. 원하는 페이지, 메인과 포인트 컬러 정하기
5. 디자이너에게 어필 하고 싶은 각자의 의견 정리 하기 이정도가 다 일것 같다. MVC 패턴을 처음 맞이 했을 때, 내가 일단 로직을 짤수 있을까 고민 했는 데.. 지금은 내가 생각 한대로 어느정도 짤 수 있는 것 같다 .. 사실 그것보다 더 많이 생각 해야 할 부분들이 많기 때문에 .. ㅠㅠ 다행이면서도 열심히 해야 겠다 .. 생각을 매번 하는 나 이다.

항해를 하면서, 연애를 하기는 진짜 어려운것 같다. 내 욕심때문에 날도 세고, 추가 작업도 하는데, 그게 남친에게는 항해가 나쁜놈으로 보였던 주 원인이였던 것 같다. 한바탕 울면서 싸우고 밥을 먹으러 가니.. 할일이 추가 되었다.

RDS...

간단하게 api만 추가 하면 되는 일이라서 만들어 주었던 것 같다. 그렇게 진정되고 새벽이 되니.. 이메일 하나가 날아 왔다 메일 내용을 간단히 하자면 , 응 .. 니 rds 터지기 직전 싫음 돈줘! 이 말이였다.

그래서 RDS를 갈아 끼웠다. ㅎㅎㅎㅎㅎ

이 문제들 말고는 따로 로직에는 문제가 없었다.

따라서 만들어 본다고 해서, 저번주 기억(명확하게는 어제의 기억)을 살려서 프론트 고생을 덜하게 하려고 프론트 맴버들의 이야기를 위주로 의견을 수렴해 보니, 트위터를 하기로 했다.

첫 단추 망함

첫 단추.. git Organization을 사용하라고 해서 레포에 올릴라고 하니, 토큰을 만들라고 한다.. 그래서 만들어서 넣어주니 너무 .. 잘 돌아간다.

갑분 에러..

2023-03-04 14:50:45.672 ERROR 7016 --- [  restartedMain] j.LocalContainerEntityManagerFactoryBean : Failed to initialize JPA EntityManagerFactory: Unable to create requested service [org.hibernate.engine.jdbc.env.spi.JdbcEnvironment]  
2023-03-04 14:50:45.672  WARN 7016 --- [  restartedMain] ConfigServletWebServerApplicationContext : Exception encountered during context initialization - cancelling refresh attempt: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'entityManagerFactory' defined in class path resource [org/springframework/boot/autoconfigure/orm/jpa/HibernateJpaConfiguration.class]: Invocation of init method failed; nested exception is org.hibernate.service.spi.ServiceException: Unable to create requested service [org.hibernate.engine.jdbc.env.spi.JdbcEnvironment]  
2023-03-04 14:50:45.675  INFO 7016 --- [  restartedMain] o.apache.catalina.core.StandardService   : Stopping service [Tomcat]  
2023-03-04 14:50:45.684  INFO 7016 --- [  restartedMain] ConditionEvaluationReportLoggingListener :Error starting ApplicationContext. To display the conditions report re-run your application with 'debug' enabled.  
2023-03-04 14:50:45.709 ERROR 7016 --- [  restartedMain] o.s.boot.SpringApplication               : Application run failedorg.springframework.beans.factory.BeanCreationException: Error creating bean with name 'entityManagerFactory' defined in class path resource [org/springframework/boot/autoconfigure/orm/jpa/HibernateJpaConfiguration.class]: Invocation of init method failed; nested exception is org.hibernate.service.spi.ServiceException: Unable to create requested service [org.hibernate.engine.jdbc.env.spi.JdbcEnvironment]  
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1804) ~[spring-beans-5.3.25.jar:5.3.25]  
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:620) ~[spring-beans-5.3.25.jar:5.3.25]  
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:542) ~[spring-beans-5.3.25.jar:5.3.25]  
at org.springframework.beans.factory.support.AbstractBeanFactory.lambda$doGetBean$0(AbstractBeanFactory.java:335) ~[spring-beans-5.3.25.jar:5.3.25]  
at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:234) ~[spring-beans-5.3.25.jar:5.3.25]  
at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:333) ~[spring-beans-5.3.25.jar:5.3.25]  
at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:208) ~[spring-beans-5.3.25.jar:5.3.25]  
at org.springframework.context.support.AbstractApplicationContext.getBean(AbstractApplicationContext.java:1154) ~[spring-context-5.3.25.jar:5.3.25]  
at org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:908) ~[spring-context-5.3.25.jar:5.3.25]  
at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:583) ~[spring-context-5.3.25.jar:5.3.25]  
at org.springframework.boot.web.servlet.context.ServletWebServerApplicationContext.refresh(ServletWebServerApplicationContext.java:147) ~[spring-boot-2.7.9.jar:2.7.9]  
at org.springframework.boot.SpringApplication.refresh(SpringApplication.java:731) ~[spring-boot-2.7.9.jar:2.7.9]  
at org.springframework.boot.SpringApplication.refreshContext(SpringApplication.java:408) ~[spring-boot-2.7.9.jar:2.7.9]  
at org.springframework.boot.SpringApplication.run(SpringApplication.java:307) ~[spring-boot-2.7.9.jar:2.7.9]  
at org.springframework.boot.SpringApplication.run(SpringApplication.java:1303) ~[spring-boot-2.7.9.jar:2.7.9]  
at org.springframework.boot.SpringApplication.run(SpringApplication.java:1292) ~[spring-boot-2.7.9.jar:2.7.9]  
at com.sparta.sweetterbe.SweetterBeApplication.main(SweetterBeApplication.java:12) ~[main/:na]  
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[na:na]  
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77) ~[na:na]  
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[na:na]  
at java.base/java.lang.reflect.Method.invoke(Method.java:568) ~[na:na]  
at org.springframework.boot.devtools.restart.RestartLauncher.run(RestartLauncher.java:49) ~[spring-boot-devtools-2.7.9.jar:2.7.9]  
Caused by: org.hibernate.service.spi.ServiceException: Unable to create requested service [org.hibernate.engine.jdbc.env.spi.JdbcEnvironment]  
at org.hibernate.service.internal.AbstractServiceRegistryImpl.createService(AbstractServiceRegistryImpl.java:284) ~[hibernate-core-5.6.15.Final.jar:5.6.15.Final]  
at org.hibernate.service.internal.AbstractServiceRegistryImpl.initializeService(AbstractServiceRegistryImpl.java:246) ~[hibernate-core-5.6.15.Final.jar:5.6.15.Final]  
at org.hibernate.service.internal.AbstractServiceRegistryImpl.getService(AbstractServiceRegistryImpl.java:223) ~[hibernate-core-5.6.15.Final.jar:5.6.15.Final]  
at org.hibernate.id.factory.internal.DefaultIdentifierGeneratorFactory.injectServices(DefaultIdentifierGeneratorFactory.java:175) ~[hibernate-core-5.6.15.Final.jar:5.6.15.Final]  
at org.hibernate.service.internal.AbstractServiceRegistryImpl.injectDependencies(AbstractServiceRegistryImpl.java:295) ~[hibernate-core-5.6.15.Final.jar:5.6.15.Final]  
at org.hibernate.service.internal.AbstractServiceRegistryImpl.initializeService(AbstractServiceRegistryImpl.java:252) ~[hibernate-core-5.6.15.Final.jar:5.6.15.Final]  
at org.hibernate.service.internal.AbstractServiceRegistryImpl.getService(AbstractServiceRegistryImpl.java:223) ~[hibernate-core-5.6.15.Final.jar:5.6.15.Final]  
at org.hibernate.boot.internal.InFlightMetadataCollectorImpl.<init>(InFlightMetadataCollectorImpl.java:173) ~[hibernate-core-5.6.15.Final.jar:5.6.15.Final]  
at org.hibernate.boot.model.process.spi.MetadataBuildingProcess.complete(MetadataBuildingProcess.java:127) ~[hibernate-core-5.6.15.Final.jar:5.6.15.Final]  
at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.metadata(EntityManagerFactoryBuilderImpl.java:1460) ~[hibernate-core-5.6.15.Final.jar:5.6.15.Final]  
at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:1494) ~[hibernate-core-5.6.15.Final.jar:5.6.15.Final]  
at org.springframework.orm.jpa.vendor.SpringHibernateJpaPersistenceProvider.createContainerEntityManagerFactory(SpringHibernateJpaPersistenceProvider.java:58) ~[spring-orm-5.3.25.jar:5.3.25]  
at org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean.createNativeEntityManagerFactory(LocalContainerEntityManagerFactoryBean.java:365) ~[spring-orm-5.3.25.jar:5.3.25]  
at org.springframework.orm.jpa.AbstractEntityManagerFactoryBean.buildNativeEntityManagerFactory(AbstractEntityManagerFactoryBean.java:409) ~[spring-orm-5.3.25.jar:5.3.25]  
at org.springframework.orm.jpa.AbstractEntityManagerFactoryBean.afterPropertiesSet(AbstractEntityManagerFactoryBean.java:396) ~[spring-orm-5.3.25.jar:5.3.25]  
at org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean.afterPropertiesSet(LocalContainerEntityManagerFactoryBean.java:341) ~[spring-orm-5.3.25.jar:5.3.25]  
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1863) ~[spring-beans-5.3.25.jar:5.3.25]  
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1800) ~[spring-beans-5.3.25.jar:5.3.25]  
... 21 common frames omitted  
Caused by: org.hibernate.HibernateException: Access to DialectResolutionInfo cannot be null when 'hibernate.dialect' not set  
at org.hibernate.engine.jdbc.dialect.internal.DialectFactoryImpl.determineDialect(DialectFactoryImpl.java:100) ~[hibernate-core-5.6.15.Final.jar:5.6.15.Final]  
at org.hibernate.engine.jdbc.dialect.internal.DialectFactoryImpl.buildDialect(DialectFactoryImpl.java:54) ~[hibernate-core-5.6.15.Final.jar:5.6.15.Final]  
at org.hibernate.engine.jdbc.env.internal.JdbcEnvironmentInitiator.initiateService(JdbcEnvironmentInitiator.java:138) ~[hibernate-core-5.6.15.Final.jar:5.6.15.Final]  
at org.hibernate.engine.jdbc.env.internal.JdbcEnvironmentInitiator.initiateService(JdbcEnvironmentInitiator.java:35) ~[hibernate-core-5.6.15.Final.jar:5.6.15.Final]  
at org.hibernate.boot.registry.internal.StandardServiceRegistryImpl.initiateService(StandardServiceRegistryImpl.java:101) ~[hibernate-core-5.6.15.Final.jar:5.6.15.Final]  
at org.hibernate.service.internal.AbstractServiceRegistryImpl.createService(AbstractServiceRegistryImpl.java:272) ~[hibernate-core-5.6.15.Final.jar:5.6.15.Final]  
... 38 common frames omittedProcess finished with exit code 0

위의 오류를 프로젝트 시작하자 마자 마주했다. .. 이제 무슨일?? 그래서 바로 뜨자 마자 트러블 슈팅에 올렸다 올리니.. 팀원이 하는 이야기는 .. application.properties 내용이 잘못 되서 그런거라고 한다. 받은 코드를 넣으니, 너무~~ 잘 돌아간다. 나에게 온 api는 4개라서 후다닥하고 서버에서 확인한 후, pull request 날리고 쉬었다.

깔끔했던 하루 였다.

주말 내내 주변의 팀원들이 개인의 사정으로 다 빠져 나가는 일이 생겼다. 작두를 탄 사람마냥 .. 갑자기 새벽에 거의 모든 api를 구현하고 3시간만에 일어나 배포를 다시 했다. 그런데 갑분.. 프론트 맴버가 찾아와 CORS 에러 매세지를 보여주었다. 이미 예측했던 문제라서 그닥 놀랍지는 않았지만.. 막상 만지려니 힘들었다.

첫번째 시도..

websecurityconfig.java 파일에서 filterchain 관련 내용에서 아래 코드를 넣고 그 맨 하단에 CorsConfiguration 메소드를 만든다. 해당되는 코드는 아래 하나더 붙어 넣고 보겠다.

http.cors();

@Bean  
public CorsConfigurationSource corsConfigurationSource() {  
    CorsConfiguration config = new CorsConfiguration();  

    config.addAllowedOrigin("http://dev-match.s3-website.ap-northeast-2.amazonaws.com/");  
    config.addAllowedOrigin("http://localhost:3000");  
    config.addExposedHeader(JwtUtil.AUTHORIZATION_HEADER);  
    config.addAllowedMethod("*");  
    config.addAllowedHeader("*");  
    config.setAllowCredentials(true);  
    config.validateAllowCredentials();  

    UrlBasedCorsConfigurationSource source = new UrlBasedCorsConfigurationSource();  
    source.registerCorsConfiguration("/**", config);  

    return source;  
}

아래와 같이 수정을 한뒤에 당당하게 프론트를 담당하는 친구에게 다시 시도 해보라는 연락을 해 보았다. 그런데.. 또 안된다는 연락을 받았다... 우씨..

두번째 시도

같이 항해를 하는 친구들중에 친한 친구에게 가서 물어 보았다. 그랬더니 .. Controller에 Annotation을 추가 하라고 이야기를 했다.

@CrossOrigin(origins = "*", allowedHeaders = "*")

위 코드까지 쓰고 나니 ..잘 돌아갔다.

spring boot 를 사용하면서 자주 쓰게 되는 클래스 였다. 안다기 보다는 다들 사용하니 나도 따라서 사용해본 클래스였다. 그래서 이해를 해야 코드를 쓰는 내 입장에서는 알아보는 게 필수였다.

• Optional 클래스는 자바8 부터 null값에 대한 처리를 더 깔끔하게 하기 위해 추가 된 클래스이다. (가독성을 위해서라나 뭐라나.. )
• null값일수도 잇는 어떤 변수도 Optional클래스로 wrapping한다고 생각하면 된다.

Example

유저 객체를 조회 했을 때, 있을 때와 없을 때를 나누어 예외 처리를 할 수 있다.

public StatusResponseDto<String> likeComment(Long id, UserDetailsImpl userDetails) {  
    Comment comment = commentRepository.findById(id).orElseThrow(
    () -> new NullPointerException("존재하지 않는 댓글")
    );  
    Optional<CommentLike> optionalCommentLike = commentLikeRepository.findByCommentAndUser(comment, userDetails.getUser());  
    if (optionalCommentLike.isPresent()) { // 유저가 이미 좋아요를 눌렀을 때  
        commentLikeRepository.deleteById(optionalCommentLike.get().getId());  
        return StatusResponseDto.success("댓글 좋아요 취소");  
    }  
    commentLikeRepository.save(new CommentLike(comment, userDetails.getUser()));  
    return StatusResponseDto.success("댓글 좋아요 성공");  
}

과제를 하면서 썼던 코드를 가져와 보았다. 위의 코드를 보면 Optional로 감싼 CommentLike가 보인다. 아래 그 객체가 존재하는 지를 isPresent로 확인해서 좋아요 취소와 추가를 처리하는 것을 볼 수 있다. (솔직히 이 객체가 없었으면... 코드 줄이 길어 졌겠다 싶은 생각이 든다. )

그 이외 Optional을 사용할때 쓸수 있는 메소드가 다양하다. 아래 링크에 그에 대한 자세한 정보가 있는 링크를 남겨 본다. https://kih0902.tistory.com/56 내일은 제네릭에 대해서 알아 볼까 한다.

어제, 코드를 고친 이후로 postman에 아무 것도 안뜨면서 403 forbidden이 뜨는 신기한 일이 발생 하였다. 멘붕... (아래 처럼 나와야 하는 데 아무 것도 안뜨고 403 forbidden으로만 뜨는.. 오류)

이유를 알아야 고치는 데, 인터넷에서 확인한 http.csrf().disable() 은 이미 되어 있었기 때문에 다른 이유를 알아 봐야 할 것 같다. 오류 코드를 보면 힌트 같으면서도, 가급적 친해지고 싶지 않은 친구 같다.

오늘, 이제 매니저님께 여쭤 본 결과 ... 한방에 해결이 되었다.

/api/user라고 되어있는데 이걸 내가 user/** 만 해도 되겠지하고 앞에 api를 안써준것이 문제가 되었다. .. 이걸로 남은 lv4는 바로 해결이 되어 버렸다.

남은 lv5문제는 다 처리가 되었고 내일은 개인 공부만 남았다 파이팅!!

SQL의 분류

• DML(Data Manipulation Language) : 데이터 조작
• DDL(Data Definition Language) : 데이터베이스의 스키마 정의 또는 조작
• DCL(Data Control Language) : 데이터 제어, 권한 관리, 데이터 보안, 무결성등 을 정의

SQL

생성, 삭제, 수정, 조회등을 자주 하게 된다. 조회도 다양한 방법을 사용하게 된다.

• table : RDBM기본적인 저장구조, 한 개이상의 column과 0개 이상의 row로 구성된다.
• column : table상에서의 단일 종류를 나타낸다. 특정 데이터 타입 및 크기를 가지고 있다.
• row : column들의 조합이다. 때로는 레코드라고 불린다. 기본키에 의해서 구분 되며, 기본 키는 중복 값을 허용하지 않는다.
• field : row와 column의 교차점. 데이터를 포함 할 수 있고, 포함 할 수 없을 때는 null값을 가진다.

DB에 관련 되어, 학교 교수님이 정리 해주신 페이지가 있다. (사실, 저작권이 있는 것 같아서 링크를 올리지는 못하겠다. 상관 없나?? 잘 모르겠다.)

DB 쿼리 문을 스프링을 사용하면서 만질 일은 없다. 그럼 sql을 어떤 식으로 만질지 나는 궁금했다. 그런 내용을 기준으로 찾아 보니, 가장 많이 나오는 내용이 JDBC라는 것을 사용해서 sql연동을 하는 내용이 가장 많이 들어 갔다.

JDBC, 그게 뭔데?

Java DataBase Connectivity의 약자 이며 자바에서 db 프로그래밍을 하기 위해서 사용되는 API라고 생각 하면 된다. (자바언어를 이용한 db접속과 쿼리문 실행, 그리고 실행 결과로 얻어진 데이터의 핸들링을 제공하는 방법과 절태에 대한 규약이알고 한다. 결론, 자바에서 db사용 할 때 쓴다는 말인거 같다..)

그럼 스프링에서 JDBC를 사용하게 되면 뭐가 다른걸까? 스프링에서는 JDBC Template를 사용한다. 스프링 dependencies에 추가를 하게 되면 아래의 종류에 해당되는 db가 연결 되고 사용이 가능 하게 된다고 한다. (사실, 아직 사용해보지 않아서 모르겠다. )

• DB2
• H2
• HSQLDB
• MariaDB
• Microsoft SQL Server
• MySQL
• Oracle
• Postgres (해당 되지 않는 db를 사용한다면, 따로 설정을 해서 사용이 가능하게 만들면 된다고 한다. ) Spring config에서 설정을 한다고 한다. (코드를 봤으나, 이해가 안되니 ... 나중에 이해가 되서 내가 쓸 수 있게 되면 추가 하고자 한다. )

아직은 나 스스로 이해가 안되는 지점이 많아서 ... 일단은 도움이 된 사이트 링크만 남기고 글을 마무리 하고자 한다. 공부를 해야 할 범위가 하면 할 수록 점점 늘어 나고 있다는 생각이 많이 든다... 뭐하나 쉽지 않지만 일단은 꾸준히 공부 해 나아가는 사람이 되면 좋겠다.

• 클래스의 모든 필드에 대한 생성자를 자동으로 생성한다.

Entity에서 자주 볼 수 있는 annotation이다. 그리고 생성자를 만들지 않아도 자동으로 만들어주는 신기한 기능을 가지고 있다. 이걸 쓴 코드는 아래 보여주고자 한다.

package com.sparta.hanghaeboard.entity;

import com.sparta.hanghaeboard.dto.CommentRequestDto;
import lombok.AllArgsConstructor;
import lombok.Getter;
import lombok.NoArgsConstructor;

import javax.persistence.*;

@Entity
@Getter
@AllArgsConstructor
@NoArgsConstructor
public class Comment extends Timestamped{

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;
    private String content;

    @ManyToOne
    @JoinColumn(name = "user_id")
    private User user;
    @ManyToOne
    @JoinColumn(name = "post_id")
    private Board board;

    public Comment(User user, Board board, String content){
        this.user = user;
        this.board = board;
        this.content = content;
    }

    public  void update(CommentRequestDto requestDto){
        this.content = requestDto.getContent();
    }


}

RequiredArgsContructor

• 클래스에서 Final필드에 대한 생성자를 자동으로 생성한다.
• final필드는 클래스에서 초기화를 하던지 객체 생성시 생성자를 이용해 꼭 초기화해줘야 한다고 한다.

이것도 자주 쓰는 annotation인데 과제를 하면서 전혀 모르고 사용했다.

GobalExceptionHadler

전역으로 예외 처리를 하는 이유는?

우리가 전역으로 예외를 처리하는 이유는 뭘까? 컨트롤러나 서비스에서 예외처리를 하다보면, 예외처리에 대한 중복 되는 코드는 늘어나고, 그로 인한 유지 보수에 어려움이 있을 것으로 예상 되기 때문에 사용한다고 한다.

전역에서 예외 처리를 어떻게 할까?

이를 위해서 @ControllerAdvice 또는 @RestControllerAdvice를 사용한다. 이 Annotation은 AOP방법이라고 한다. 어플리케이션내에서 전역적으로 발생하는 모든 예외를 한 곳에서 관리할 수 있게 한다.

오류 처리를 하면서 StatusResponseDto를 만들어서 처리를 해 보았다. 생각 보다 어려웠고 Spring Generics에 대해서 공부해야 겠다는 생각을 하게 되었다.

위에 해당 되는 코드는 내 깃 허브 링크를 통해서 올려 보고자 한다. 주변 지인들에게 도움을 많이 받아서 만든 과제라고 생각 한다. .. 부끄럽지만 올려 본다. https://github.com/colleenInKorea/hanghaeBoard_w2.git

Websocket

TCP연결을 통해서, 양방향통신 체널을 제송하는 기술이다. 간단하게 만들어 본 결과로는 실시간 채팅의 경우 사용하는 것을 경험 해 보았다. 하지만 spring이 아닌 node.js로 학교 과제에서 만들어 본것 이기 때문에 완성도에서는 생각 보다 별로 였다.

SSE

(Server Sent Events) SSE는 웹소켓과 비슷하지만 다른경우라고 들었다. SSE같은 경우, 실시간 검색어나 주식정보, 날씨정도들의 자주 바뀔 수 있는 데이터에 사용하면 좋은 것이다. SSE 역시 HTTP프로토콜에 의해 동작한다. 그리고 이 방법은 서버에서 업데이트가 필요할 때마다 클라이언트에 일방적으로 데이터를 전송해준다. (매니저님께 여쭤 보았더니, 실시간 알림으로 사용했다고 하셨다. )

Websocket 과 SSE의 차이점

둘의 가장 큰 차이점은 웹소켓이 양방향으로 데이터를 주고 받는 다면 SSE는 일방적으로 데이터를 클라이언트에 뿌린다는 점이다. 둘의 차이는 아래 사이트에 자세하게 쓰여 있다. 확인하면 좋을 거 같다. https://surviveasdev.tistory.com/entry/%EC%9B%B9%EC%86%8C%EC%BC%93-%EA%B3%BC-SSEServer-Sent-Event-%EC%B0%A8%EC%9D%B4%EC%A0%90-%EC%95%8C%EC%95%84%EB%B3%B4%EA%B3%A0-%EC%82%AC%EC%9A%A9%ED%95%B4%EB%B3%B4%EA%B8%B0