Entity는 setter를 안만들어주는게 좋다.
Entity는 id로 구분한다
@ManyToOne(fetch전략)
boundary - 구분자 / 랜덤한 글자
-------WebKitFormBoundary어쩌구가 나눔구간
나눠서 클라이언트가 보낼때 각각 하나하나 content-type이 지정되어있음
postman에 나눠서 보내쟈 form-data로파일 업로드
content-type보이게 해주자
@RequestPart로 받는다
파일을 보낼때 변수이름을 맞춰줘야한다.
윈도우와 리눅스는 파일저장경로가 다르다. 그래서 File.separator를 추가해줌
파일 저장메소드 로컬에 파일이 저장되게 해놨음
파일업로드
2개의 서비스를 만들거임
- local에 저장함
- cloud에 파일을 저장함
파일을 전달받아서 저장한다 라는 조건이 같음.
파일업로드 서비스인터페이스
로컬에 파일을 저장하는 서비스
클라우드에 파일을 저장하는 서비스
LocalFileUpload service의 코드만 잘 만들면 가져다쓰는 코드는 바뀔게 없다 -> 다형성
다형성이라는 특징을 살려서 코드를 짤 수도 있다.
@Service를 달면 해당 파일이 서비스파일이 되므로 로컬을 만들었다가 클라우드로 바꿀 수 있음
@Qualifier("LocalFileUploadService") - 비슷한애들이 의존성주입받을때 이름을 붙여주는 어노테이션
이럴때 단방향이 좋을까 양방향이 좋을까?
주문을 통해서 회원을 가져오는게 없다. 회원을 통해서 정보를 가져오는건 있기 때문!
uuid사용하는게 좋다
Cloud
남의 컴터 사용하는거?
IDC센터
남의 컴터 씀
위 두개는 뭐가 다른걸꺄
클라우드 - 남의 가상화 컴터 쓰는거
IDC센터 - 남의 컴터쓰는거
가상화를 만드는 큰 2가지
나만의 클라우드 만드는 프로그램
1. 가상머신기반 - 오픈스택
2. 컨테이너기반 - 쿠버네티스
웹어플리케이션역할
웹서버가 하는일 - 서버컴터에 잇는거 다운로드시켜주는거
버킷자체를 웹서버로 쓰기도함
가상컴터를 빌려서 쓰면 시간당 요금이 나옴.
ARN : arn:aws:s3:::practice240625/* //arn:aws:s3:::{KeyName}
Generate버튼누르면 정책생성
정책에 복붙
yml파일에 cloud설정 access-key랑 secret-key는 aws에서 발급받아야함!
Lombok을 사용하면 어노테이션을 가지고 만들 수 있음음
디펜던시에 추가
compileOnly group: 'org.projectlombok', name: 'lombok', version: '1.18.30'
lombok 플러그인에서 설치 후 annotation설정
@NoArgsConstructor - 기본생성자
@AllArgsConstructor - 모든매개변수를 받는 생성자
@Builder
builder사용
불변성 - dto는 전달을 받고 응답을 줌. controller에서받아서 service에 넘기고있는데, dto의 값을 바꿀 수 있음. db에서 조회한거를 바로 전달해주자인데, 불변객체로 전달해준다 말그대로 변경불가! setter만들지말고 builder객체로 만들어서 딴사람이 못바꾸게 하자!가 목적. 다른사람이 변경하지 못하도록 할 수 있다.
dto에 다 지우고 setter없애고
객체를 생성할때부터 값이 세팅이 되도록 builder로 수정 근데 이것도 좋은 코드는 아님
객체생성도 builder로 만듦
static으로 만들면 static끼리 메모리를 공유하니까 그냥 만드는것보다 메모리를 줄일 수 있다.
static으로 만들었을때 사용하는법
이거까지 추가해야함
빌더는 유연성이 높다
보통 DTO나 Entity에 자주 쓰인다
불변객체이기 때문에 값을 전달해주는 역할인 DTO와 Entity는 중간에 값이 변경되거나 하는일이 없어야하기 때문에 setter가 없는게 좋고 builder를 쓰는게 좋다
Builder의 장단점 언제 사용하는지 어떻게 사용해야하는지 공부하는게 좋다
단점: 클래스위에 빌더를 선언하면 모든 멤버필드에 대해서 매개변수를 받는 생성자를 만든다.
dto에 값넣는 코드는 dto클래스 내부에 있는게 좋은데 상황에 따라 다르다.
클래스안에 클래스는 안에 static으로 해주는게 좋다.
