ResponseEntity를 이용한 메세지와 상태코드 반환
🔺 에러발생은 하지 않았지만 테스트가 필요하여 진행중임 🔺

Lombok 의 @RequiredArgsConstructor 를 사용하면 다음과 같이 코딩 가능

@RestController
@RequiredArgsConstructor // final로 선언된 멤버 변수를 자동으로 생성합니다.
public class ProductController {

    private final ProductService productService;
    
    // 생략 가능
		// @Autowired
		// public ProductController(ProductService productService) {
		//     this.productService = productService;
		// }}

@PostConstruct란?(정의와 장점)

1. @PostConstruct란?

@PostConstruct는 의존성 주입이 이루어진 후 초기화를 수행하는 메서드이다. @PostConstruct가 붙은 메서드는 클래스가 service(로직을 탈 때? 로 생각 됨)를 수행하기 전에 발생한다. 이 메서드는 다른 리소스에서 호출되지 않는다해도 수행된다.

출처: Oracle Doc

2. 왜 사용하는가(장점)?

1) 생성자(일반)가 호출 되었을 때, 빈(bean)은 아직 초기화 되지 않았다. (예를 들어, 주입된 의존성이 없음)

하지만, @PostConstruct를 사용하면, 빈(bean)이 초기화 됨과 동시에 의존성을 확인할 수 있다.

개인 의견으로 클래스 내에 @Autowired를 붙여서 객체를 사용할 때, 생성자가 필요하다면 @PostConstruct를 사용하면 될 것 같다. 빈(bean)이 등록되고 사용할 수 있으니까 말이다. 나도 그렇게 사용했고..

2) bean lifecycle에서 오직 한 번만 수행된다는 것을 보장할 수 있다. (WAS가 올라가면서 bean이 생성될 때 딱 한 번 초기화함) 그래서 @PostConstruct를 사용하면 bean이 여러번 초기화되는 것을 방지할 수 있다.

궁금

궁금2 @ResponseBody 와 @RequestBody

@RequestBody 어노테이션이란?

HTTP 요청의 body 내용을 자바 객체로 매핑하는 역할을 합니다.

@ResponseBody 어노테이션이란?

자바 객체를 HTTP 요청의 body 내용으로 매핑하는 역할을 합니다.

• 위의 예제 소스에서는 HTTP 요청의 body안에 Member 데이터를 파라미터로 받기위해,

  @RequestBody를 사용하였습니다.

  @ResponseBody를 사용하지 않은 이유는 @RestController를 사용하였기 때문입니다.

  @Controller와는 다르게 @RestController는 리턴값에 자동으로

  @ResponseBody를 붙게되어 HTTP 응답데이터(body)에 자바 객체가 매핑되어 전달됩니다.

  ( ※ @Controller인 경우에는 @ResponseBody를 적어줘야 합니다. )

궁금3

//회원중복확인
        Optional<User> found = userRepository.findByUsername(username);
        if(found.isPresent()){
            throw new IllegalArgumentException("중복된 username 입니다.");//statuCode:400 에러메시지와 같이 반환
        }

옵셔널???

궁금4 @Transactional(readOnly = true)

@Transactional 작업을 처리하기 위해 많은 리소스가 사용됩니다.
특히 CUD sql문에서는 이전 상태로 돌려야하기 때문에, 이전 상태를 가지고 있어야합니다.
하지만 select문 같은 경우는 쿼리를 실행해도 이전 상태와 변화가 없으므로 해당 transaction에 lock을 적용할 필요가 없습니다.

그렇기때문에 (readOnly = true) 옵션을 사용하여 해당 메서드가 읽기 전용이라는 것을 명시하고, 영속성 컨텍스트에 관리를 받지않게 됩니다.
또한 변경감지 수행등을 하지 않아 @Transactional의 격리 수준보다 낮은 수준의 격리 수준을 사용하게 됩니다.

여기까지 알고 난 후, 의문이 하나 들었습니다.

그렇다면 JPA를 쓰지 않는다면 굳이 왜 @Transactional(readOnly = true)를 사용할까? 그냥 transaction 어노테이션을 사용하지 않아도 되지 않나?

그래서 @Transactional(readOnly = true) 사용했을 때의 장단점을 살펴보려고 합니다.

장점
readOnly라고 명시하므로 읽는 개발자가 읽기 전용 메서드라는 것을 알 수 있습니다.
JPA를 사용할 경우, 변경감지 작업을 수행하지 않아 성능상의 이점이 있습니다.
트랜잭션 ID 설정에 대한 오버헤드를 해결하고, 스냅샷을 통해 데이터의 일관성을 보장한다.
CRUD를 하는 service에서 클래스에 @Transactional을 붙여 중복을 줄이고 싶을 때 read 메서드에 사용하여 격리 수준을 바꿔줄 수 있다.
단점
사용하지 않았을 때보다 자원(프록시)을 사용하므로 느리다.
참고

보충강의

1. lombok 사용시 @Data 사용 지양 , ->? @Setter
2. @Setter 쓰는 대신 -> @Getter + @NoArgsContsructor 로 set 됨
   원래 @Setter대신 @AllArgsContructor 사용했지만 변경사항이 없으므로 굳이 사용할 필요 없다고 하심
3. @Controller ->thymeleaf
4. Application = Service + Entity -> @Service ,@Component
5. Controller(UI)(presentation) @RestController, @RequestBody : 벡엔드 입장에서는 그림그리는 거랑 같음
6. 요구사항 볼때 -생성 쪽을 먼저 보는 팁
   7.@Transactional 은 앞에 저장하고나서 에러가 나면 저장이 일어나지 않고, 만약 어노테이션이 없으면 에러가 있어도 저장이 일어난다. ....
   묶어서 날린다.? 다시 한번 알아보기
   8.게시글에게 패스워드 확인의 기능을 주는게 객체지향적
7. dto -> service ->controller (클라이언트에게 보여줄 값을 반환)??