[CS] 백엔드 기초 스터디 6일차.
@Spring Managed Components
이걸 가지고 거의 모든게 만들어져 있다.
컴포넌트 특징 가져가면서 개별적인 내용 가져가는 거들
비즈니스 레이어 (실제 제공하고자 하는 ) persiste layer:
database layer : 실제 디비
위 그림에 맞춰 실제 어노테이션이 추가가 된 것.
- 간단한 서비스를 통해 확인해보자
- Wav Header Removal Service
- Post 요청으로 Wav 파일을 받고 그 헤더를 제거하는 서비스.
초 당 샘플레이트가 얼마인지. 길이가 얼마인지 이런 데이터를 앞에 붙여놓은 44~46바이트를 따로 만들어놨는데 오디오 헤더에서 이걸 해석하고
1초동안 파동의 영향이 있을텐데 미분해서 저장해야 할 텐데 어떤 사람은 1만번 기록, 어떤사람은 5천기록 해놨다 치고만 번기록하면 5천개의 데이터 재생하
순수한 데이터에는 이런 데이터가 부족해서 저장하기 위해 wav가 필요
실제로 음성 데이터는 이런게 포함된게 아니라 따로 앞에 저장해둔게 일반적인 음성 파일.(덤)
연구목적에서 파일은 이 헤더가 없어야 한다. 이 wav 파일로 제공된 파일의 헤더 제거하고 순수한 데이터(pcm데이터로 바꾸는 거)
data가 실제 가져오려는 부분이고 실제 찾으려는 헤더부분이 subchunk2id부분
그 데이터를 찾는데 존재하지 않으면 wav파일이 아니라 생각 가능.
이게 터지면 스프링에서 자동으로 400에러 띄워줌.
서비스 부분
raw 데이터(pcm데이터)가 어디있는지 저장. 응답에 있는 아웃풋 스트림에 방금 돌려받은 인풋 스트림 돌려받음. (바이트 위에 2줄을 지워줘야)
뒤에 부분이 순수 데이터 부분이니까 그 부분만 돌려보내면 된다.
multipart로 보낼 수 있는 한계를 넘어섰다는 포스트맨 에러가 난다.
유니코드를 변환하는 데이터로 바꾸는 과정에서 이렇게 나옴.
맨 위
이 부분을 서로 다른 컴포넌트로 구성
클라이언트와 실제로 요청 받는 컴포넌트
서비스 컴포넌트는 일반적인 관점에서 독립적으로 작동할 수 있는 비즈니스 로직을 넣어둠. 실제 데이터를 받은거에서 데이터 헤더를 받은거에서 돌려받음.
서비스로 만들어진 객체의 바운더리는 일부분이 아니더라도
컴포넌트는 어디서든 사용 가능.
컴포넌트 부분에 컨트롤러에 들어가도 문제는 없는데 맞는 요청인지 사람이 권한을 가진 사람이 한 요청인지를 컴포넌트 부분에 넣어둠.
마지막으로 configuration에서 애플리케이션이 실행되면 설정을 정의하고 주입 받을 수 있게 해준다.
안에는 Bean이라는 게 추가로 들어가 있따.
실제 필요한 설정 가지고 올때 쓰라는 거
Dao는 실제로 디비와 연결되서
나열 그러한 어노테이션으로 매칭 된 애들은 이런 식으로 사용 하게 해달라고 요청함.
이게 내부적 구현에서 사용법이 다른데 이걸 겉으로 사용함으로서 구조적 장점을 가져감으로서 컴포넌트밖에 없었는데 추가적으로 Repository등이다
사실 구분 안하고 써도 되긴 하지만(가능은 하지만) 좋지 않은 방법이다.
Clean Architecture
로버트 C.마틴이 제안
패키지 단위로 나눠서 정리가 잘 되고 wav헤더가 만들 수 있음.
유스케이스도 컨트롤러에 포함이 되긴 하는데 프로젝트 커지면 큰 파일을 묶어서 보낼 수 있는데 Usecase를 맞춰서 나누는 용도로 사용이 가능함. PostMapping은 매핑에만 신경쓰도록
코어에다가 서비스를 넣을 것. 이 서비스는 아까 만들어 둔 서비스가 아니라 인터페이스 제공해서 사용하는 용도로 되고
실제로 하고자 하는 비즈니스 로직엔
클린 아키텍쳐는 내부로 들어갈수록 상세한 정보 다루면서 자기 윗단게와 소통하면서 들어간다.
유스케이스는 하나의 파일 안에 들어가는게 맞는데 이런식의 상황이 들어갈 떄도 아까와 같았으면 어케 될까.
각각 애플리케이션에서 서로다른 계층 역할 나눠놓고 위 아래 맞닿아있는 개념을 가지고 만들어야 한다.
읽기 편한 코드를 위해 알아야 하는 코드였따.
Interface가져왔는데 import문 했는데 이 인터페이스 한 컴포넌트 객체를 찾으면 되는데
wav서비스 구현한 객체가 하나가 아니라 둘중 뭐 넣어야 되는지 모름.
primary어노테이션은 우선적으로 사용해라는 어노테이션을
beta는 구현해야 되는거인데 아무튼 구현함.
원래 코드 없애고 올리는 게 아니라 얘를 우선적으로 사용해 주세요 이런식으로 사용도 가능하다.
Spring IOC 입장에선 인터페이스 기준으로 구현체를 가져다 쓰게 하는게 맞다.
그 내부의 구현체와 밑층의 계층 단에 결합성을 줄이기 위해 의존성이 줄어든다고 보면 된다.
계층간의 결합성. 서로에 대한 의존성을 줄이기 위해 인터페이스를 만들고 그거 구현체를 만든다.
구현체가 인터페이스를 무조건 따라야 되서 잘못된 변경을 할 수도 없다.
inputStream도 추상클래스라 이 구현체에 대한 거도 또 클래스가 존재( OOP에 대한 얘기)
어떤 inputStream이 들어갈 수 있음.
inputStream이 추상클래스 돌려줘서 ByteArrayInputStream inputStream, outputStream 많이 쓸건데 이 바이트 에 대한 출처는 여러개가 될 수 있따.
실제로 메모리 상에서 구현된거에서 사용 가능 할 수 있고 FileInputStream 도 시스템상 파일에서 그 inputStream을 받아올 수 있다.
실제 메모리 상에 있는 걸 읽을 건지 방식을 달리 할 수 있다.
추상 클래스 만들어 놓고 무조건적으로 필요로 하는 함수 내부들을 정의해두고 실제 작동 원리를 나눠서 구분하는게 이러한 예시 일 수 있다.
OOP가 생각보다 많이 중요함.
자바 기준으로 해서 ArrayList를 선언하지 않고 List를 쓰자
항상 뭔가 만들 떄 인터페이스를 만들어서 사용할 수 있도록 해야한다.
어레이 리스트도 리스트 상속 받는 객체인데 여기서 인터페이스 List를 받고
이렇게 바꾸면 에러가 나는데 리스트의 상속 받은 객체인 어레이 리스트인데
이게 DI의 예시
리스트가 상위 객체고 어레이리스트가 하위 객체인데 어레이리스트는 리스트는 리스트 하는 일 다할 수 있지만 반대는 안됨. 그래서 어레이리스트는 리스트의 모든기능 다 가능하지만 반대는 안되서
이런식으로 소통하는 함수 만들떄는 인터페이스, 추상클래스를 기준으로 만드는 게 좋다.!!!(OOP의 DI의 개념).
반대로 List는 안됨. 물론 뭐 getter,setter등 이런거
이 기초적인 코딩 보고 이게 무엇이며 어떻게 작성하고 해결해야 되는지. 에러를 많이 내고 직접 문제 해결하고 하는게 중요하다고 생각. 에러에서
질문 하기 위한 4단계
우아한 테크코스에서 질문의 4단계
- 할수 있는만큼 한다.
- 검색한다.
- 실패 사례를 정리한다.
- 그걸 가지고 찾아간다.
사실 인터넷 검색하면 굳이 찾아와서 물어본다고 한다. 일단 부딪히자.
일단 해보면 늘수 밖에 없다.
로그인은 어떤 데이터 받고 어떻게 하고 이걸 다뤄주세요 하는 경우도 있고
등등
RDB 외에 Data Handling
- 관계형 데이터베이스의 한계
- 데이터 저장 방식
스케일 업은 실제 사용하는 하드웨어나 스펙 높여 대응성 올림.
동일한 하드웨어 여러개 높여서 대응성 높임
둘다 대응성 관련 요즘은 스케일 아웃이 더 중요성이 높아진다고 함
NOSQL은 새로운 데이터 저장방식이 생겨남.
되게 작은 범위에서 아
NOSQL 은 되게 좁은 범위에서 사용? 관계형으로 사용 안하면 다 NOSQL이라 부를 수 있따.
### Redis
메모리 상에서 key-value로 저장하기 위한. remote dictionary server
딕셔너리로 저장하고 캐시의 용도로 많이 사용한다.
https://www.objectrocket.com/blog/how-to/top-5-redis-use-cases/
일반적으로 json을 컬렉션에 저장함. 얘가 같은 컬렉션이라는 사용자의 인식만 있으면 저장가능
거기 필드 기준으로 색인 , 검색 기능이 포함 가능
코드가 컬럼이 다른 항목도 추가가 가능.
.
여기서 보드가 여러개가 되면?
제너럴 보드에 카테고리 넣는다던지
카테고리 정의가 되어 있으면 카테고리 별로 게시판 추가적으로 생성 가능.
이 상태에서는 카테고리가 100개까지 늘어나도
table categories 해서
카테고리 하나만 만들어서
카테고리가 board 분류에 기준이 되고 이런식으로 나눴을 떄 장점은 user와 카테고리 간에 관계 생성 가능.
언제나 개선이나 변경사항에 대해 대응을 할 방법을 생각해 두는 게 좋다.
헤더 태그 들어가야.
가르쳐주는거 이상을 해야 개발자로 살아남을 수 있다.
42
