뚭

https://www.youtube.com/watch?v=hjDSKhyYK14

설명을 너무 잘하셔서 일단 올려봅니다 ㅎ 

1. FetchType.EAGER (즉시 로딩)

• 장점:
  • 연관된 엔터티가 항상 함께 로딩되므로, 엔터티 사용 시 추가적인 쿼리 없이 바로 사용 가능.
• 단점:
  • 항상 연관된 엔터티를 함께 불러오므로, 필요하지 않은 데이터까지 로드될 수 있다.
  • 결과적으로 성능 문제가 발생할 수 있으며, 불필요한 네트워크 및 메모리 리소스가 사용될 수 있다.

2. FetchType.LAZY (지연 로딩)

• 장점:
  • 실제로 연관된 엔터티에 접근할 때만 데이터베이스로부터 로딩한다. 따라서 필요한 경우에만 쿼리가 발생.
  • 성능 최적화에 도움을 줄 수 있다. 불필요한 데이터를 로딩하지 않으므로 자원을 효율적으로 사용할 수 있다.
• 단점:
  • 첫 접근 시 추가적인 쿼리가 실행됨. 즉, 처음 연관된 엔터티에 접근할 때마다 쿼리가 실행될 수 있다.
  • 트랜잭션 밖에서 지연 로딩을 시도하면 LazyInitializationException이 발생한다.

대부분의 상황에서 모든 연관된 엔터티를 즉시 로딩하는 것은 비효율적입니다. 특히, 관계가 복잡한 큰 애플리케이션에서는 많은 데이터가 불필요하게 로딩될 수 있습니다. 그러나 상황에 따라 연관된 엔터티를 항상 함께 로드해야 하는 경우도 있습니다. 이런 경우에는 EAGER 전략을 사용하여 즉시 로딩을 할 수 있습니다.

Lazy Loading이란?

Lazy Loading은 연관된 엔터티(Entity)를 즉시 불러오지 않고, 해당 엔터티에 실제로 접근될 때까지 로딩을 지연시키는 방법입니다. 예를 들어, 게시글(Notice)과 댓글(Comment)이 있고, 게시글에서 댓글을 Lazy Loading으로 설정했다고 가정해봅시다. 이 경우, 게시글을 불러올 때 연관된 댓글들은 즉시 로딩되지 않습니다. 댓글에 실제로 접근(예: notice.getComments())할 때 데이터베이스에서 댓글 정보를 불러오게 됩니다.

https://junit.org/junit5/docs/current/user-guide/

(자주 사용되는듯 해서 작성해봤습니다.)
@Mock: 이 어노테이션은 Mockito 라이브러리와 함께 사용됩니다. @Mock 어노테이션은 가짜(mock) 객체를 생성합니다. 해당 객체는 실제 객체처럼 동작하도록 설정할 수 있습니다.

@InjectMocks: Mockito에서 해당 어노테이션은 mock 객체를 대상 객체에 주입합니다. 주로 테스트하려는 클래스의 인스턴스에서 사용됩니다.

@Test: @Test 어노테이션은 해당 메소드가 단위 테스트 메소드임을 나타냅니다.

when() 및 thenReturn: 이것들도 Mockito의 메서드들입니다. when()은 특정 메소드 호출을 가로채서 그에 대한 동작을 정의하는 데 사용되며, thenReturn은 가로채진 메소드 호출의 반환값을 지정하는 데 사용됩니다.

mockMvc: Spring Test에서 제공하는 MockMvc는 웹 서버 없이 스프링 MVC의 동작을 테스트하기 위해 사용됩니다.

andExpect: MockMvc의 perform() 메소드 후에 연결되어 특정 조건을 검사합니다. 예를 들면, HTTP 응답 상태 코드나 응답 본문의 내용 등을 검사하는 데 사용됩니다.

jsonPath: andExpect 메소드와 함께 사용되며, JSON 응답 본문의 특정 부분을 검사하는 데 사용됩니다.

contentType 및 content: 이들은 MockMvc의 andExpect 메소드와 함께 사용되며, 응답의 Content-Type이나 본문의 내용을 검사하는 데 사용됩니다.

perform: MockMvc의 perform() 메소드는 HTTP 요청을 수행하며 그 결과를 검사하는 데 사용됩니다.

가장 큰 차이점 

JpaRepository는 빠른 개발과 표준 CRUD 연산에 초점을 맞춘 반면, EntityManager는 보다 세밀한 데이터베이스 연산과 엔터티 관리에 사용됩니다. 실제 프로젝트에서는 종종 두 인터페이스가 함께 사용되기도 합니다.

1. 정의와 목적:
   • JpaRepository: Spring Data JPA의 일부로 제공되는 인터페이스로, 주요 CRUD 연산을 위한 여러 메서드를 미리 정의해둔 것입니다. 사용자가 별도의 구현 없이 빠르게 데이터베이스 연산을 수행할 수 있게 해줍니다.
   • EntityManager: JPA의 핵심 인터페이스로, 엔터티의 생명주기를 관리하며 데이터베이스와의 상호작용을 위한 API를 제공합니다. 보다 세밀한 데이터베이스 연산이 필요한 경우에 사용됩니다.
2. 기능:
   • JpaRepository: save, findAll, delete, findById 등의 기본 CRUD 연산을 위한 메서드가 미리 정의되어 있습니다. 또한, 쿼리 메서드의 이름 규칙을 따라 메서드를 정의함으로써 직접 쿼리를 작성하지 않고도 데이터베이스 연산을 수행할 수 있습니다.
   • EntityManager: persist, merge, remove, find, createQuery 등의 메서드를 제공하여 직접 엔터티 객체와 데이터베이스 간의 상호작용을 수행할 수 있습니다. 사용자는 필요에 따라 JPQL (Java Persistence Query Language)나 Criteria API를 사용하여 복잡한 쿼리를 작성할 수 있습니다.
3. 사용 시기:
   • JpaRepository: 대부분의 표준적인 CRUD 연산이나 간단한 쿼리에 대한 처리를 할 때 사용됩니다. 빠른 개발 속도와 쉬운 유지보수를 위해 많이 활용됩니다.
   • EntityManager: 특정 엔터티의 생명주기를 세밀하게 관리하거나, 복잡한 쿼리와 데이터베이스 연산을 수행할 필요가 있을 때 사용됩니다.
4. 확장성:
   • JpaRepository: 기본적인 메서드 외에도 사용자 정의 쿼리를 추가할 수 있습니다. 그러나 복잡한 연산을 수행하기 위해서는 종종 EntityManager를 사용해야 할 수도 있습니다.
   • EntityManager: 사용자가 필요에 따라 완전히 맞춤화된 데이터베이스 연산을 수행할 수 있게 해줍니다.

제 코드가 JpaReporitory로 해결할수 있는 부분들까지  EntityManager로 작성했다는게 큰 미스였습니다. 

그래서 세밀하게 db를 변경 시키는 작업이 아니면 JpaReporitory로 변경하도록 하려고 합니다. 

RedirectAttributes는 Spring Framework의 Spring MVC에서 사용되는 인터페이스로, 리다이렉션 시점에 속성을 추가하는 데 사용됩니다. 일반적으로 컨트롤러 메서드에서 RedirectAttributes 인스턴스를 메서드 매개변수로 받아 리다이렉션 후에도 데이터를 유지할 수 있게 합니다.
 
여기는 RedirectAttributes를 사용하는 간단한 예입니다:

public String update(RedirectAttributes redirectAttributes) {
    redirectAttributes.addFlashAttribute("message", "Update successful");
    redirectAttributes.addAttribute("status", true);
    return "redirect:/view";
}

 
p.s. 이제는 스피링 db 관련해서 강의를 들으려고합니다.
김영한 개발자님 강의가 정말 쉽고 자세하게 설명해주시네요. 그리고 생각보다 지금 고쳐야할 코드부분이 많다고 느껴지네요.
https://www.inflearn.com/course/%EC%8A%A4%ED%94%84%EB%A7%81-mvc-1

Spring MVC에서 클래스 레벨과 메서드 레벨에 URL을 매핑하는 방법에는 몇 가지 차이점이 있습니다.

1.클래스 레벨에서의 URL 매핑:
클래스 레벨에서 URL을 매핑하면, 해당 URL 접두사가 해당 컨트롤러 클래스에 있는 모든 요청 매핑 메서드에 적용됩니다. 이를 통해 관련된 작업을 그룹화하여 코드의 조직화를 개선할 수 있습니다.

@RestController
@RequestMapping("/users")
public class UserController {

    @GetMapping("/{id}")
    public ResponseEntity<User> getUserById(@PathVariable Long id) {
        // ...
    }

    @GetMapping("/list")
    public ResponseEntity<List<User>> getUserList() {
        // ...
    }
}

2.메서드 레벨에서의 URL 매핑:

메서드 레벨에서 URL을 매핑하면, 해당 URL은 단순히 해당 메서드에만 매핑됩니다. 이를 통해 메서드별로 다른 URL을 지정할 수 있습니다.

@RestController
public class UserController {

    @GetMapping("/users/{id}")
    public ResponseEntity<User> getUserById(@PathVariable Long id) {
        // ...
    }

    @GetMapping("/users/list")
    public ResponseEntity<List<User>> getUserList() {
        // ...
    }
}

정리:
클래스 레벨 매핑: 관련된 메서드를 그룹화하고 코드를 더 깔끔하게 만들어줍니다. 일종의 네임스페이스 역할을 합니다.
메서드 레벨 매핑: 메서드마다 다른 기본 URL을 제공할 수 있어 유연성이 증가하지만, 코드가 조금 더 분산될 수 있습니다.
어떤 방식을 선택할지는 특정 애플리케이션의 요구 사항과 개발자의 선호에 따라 달라집니다.

ps 회사 레거시 코드들이 메서드 방식으로 레벨매핑이 되어 있어서 항상 그런식으로 했는데요.

김영한 개발자님 강의를 듣는데 클래스 레벨 맵핑으로 하시길래 궁금해서 찾게 되었습니다.

차이점은 개발 상황에 따라 달라지는듯합니다. 근데 저도 클래스 레벨 매핑이 조금더 마음에 드네요.

기존 코드는 클래스 레벨 매핑 방식으로 변경할 예정입니다.

• 요청의 경우
  @RequestBody 를 처리하는 ArgumentResolver 가 있고, HttpEntity 를 처리하는 ArgumentResolver 가 있다. 이 ArgumentResolver 들이 HTTP 메시지 컨버터를 사용해서 필요한 객체를 생성하는 것이다.
• 응답의 경우
  @ResponseBody 와 HttpEntity 를 처리하는 ReturnValueHandler 가 있다. 그리고 여기에서 HTTP 메시지 컨버터를 호출해서 응답 결과를 만든다.

스프링 MVC는

@RequestBody @ResponseBody 가 있으면
RequestResponseBodyMethodProcessor (ArgumentResolver)

HttpEntity 가 있으면 HttpEntityMethodProcessor (ArgumentResolver)를 사용한다.

https://www.inflearn.com/course/%EC%8A%A4%ED%94%84%EB%A7%81-mvc-1