토비의 스프링 6 - 이해와 원리대시보드

제 개인적인 문제인지는 모르겠습니다만,수업 자료를 다운로드 하는 버튼을 클릭 시다운로드 된 압축 폴더(zip) 내에 아무것도 들어가 있지 않고,압축 풀기시에도 오류가 발생하고 있는데,어떻게 해결할 수 있는 방법이 있을까요?

spring data jpa를 사용하면, JpaRepository 를 상속한 인터페이스를 보통 정의하게 되잖아요? 이 경우에도 특정 기술에 의존한다고 볼 수 있는건가요? 이런 경우, 실질적으로 spring data jpa 와 관련된 import 구문이 들어오기는 하지만, 구현체의 내용이 없기 때문에 코드 변경에 따른 여파가 없다고 느껴지긴 하거든요. 만들면서 배우는 클린 아키텍처라는 책에는 이를 persistence layer 로 분류하고 있더라구요. 이 인터페이스는 어떤 레이어에 속한다고 보시나요?질문을 드린 이유는 실제 헥사고날 아키텍처나 이런 것들을 다루는 곳에서 보면, 비즈니스 레이어에 인터페이스를 선언하고 이를 상속하는 인터페이스를 구현하는 경우들이 있는데, 실제 구현내용이 없는데 persistence layer 라고 봐야하나? 라는 생각이 문득 들었습니다. 예시:// business layer 에 선언interface BusinessRepository {}// persistence layer에 선언interface DataAccessRepository: JpaRepsitory<생략>, BusinessRepository

안녕하세요. 좋은 강의 감사합니다.기존에는 PaymentService 클래스의 prepare 메서드 내부에서 provider 객체를 생성했었습니다.강의 중간에 토비님께서 provider를 클래스 필드로 변경하시고, 생성자에서 객체 생성을 하셨습니다.변경 이후에 Provider는 PaymentService와 생명주기를 함께합니다.(생명주기라는 단어가 올바른지 모르겠네요.) PaymentSerivce가 메모리 해제되지 않으면, Provider도 계속 메모리를 차지하게 됩니다.하지만 메서드 레벨에서 객체 생성을 한다면, Provider는 GC에 의해 비교적 일찍 메모리 해제가 될 수 있을 것 같습니다. 제 생각에는 클래스와 메서드의 호출 패턴에 따라서 선택이 달라질 것 같은데,토비님께서는 클래스 필드 레벨 선언과 메서드 레벨 선언을 정하시는 룰이 있으신지 궁금합니다!

안녕하세요 토비님.OrderRepository 인터페이스가 application layer에 있고,이걸 구현한 구현체가 persistence layer에 있는데요. 일반적인 layered 아키텍처라고 하면, 의존성의 방향이 아래로 향해야하는데, 이 경우라면 의존성이 application 으로 향하게 되는거 같은데요. 만약에 이런식으로 구성한다면 port & adapter 같은 개념을 별도로 두지 않더라도, 의존성방향에 의하면 헥사고날 (혹은 클린 아키텍처) 라고 부를 수 있는건가요? 아니면 그럼에도 layered 아키텍처라고 부르나요?

안녕하세요! 토비님 같은 버전의 jdk에서도 zulu나 강의에서 예시로 다운받으신 liberica와 같이 회사가 다른데 혹시 그들만의 차이점이 있을까요?

안녕하세요. 토비님.좋은 강의 만들어주셔서 감사합니다.질문이 하나 있습니다.개발환경 세팅에서 bash 명령어를 추천해주는 툴? 플러그인을 사용하고 있는것으로 보이는데요.무엇인지 알려주시면 좋겠습니다.

안녕하세요 토비님 😄 강의 맛있게 잘 보고 있습니다.마이너 한 질문인데, 테스트에 Clock 을 이용한 테스트에서 6.50 초 쯔음 아래 와 같은 fixed <- 의 유형 ? 을 정적 팩토리 메서드라고 하셨는데 객체를 반환하기 위해 static 키워드를 사용해야 정적팩토리 메서드가 아닌지 여쭤봅니다@Bean public Clock clock() { return Clock.fixed(Instant.now(), ZoneId.systemDefault()); }

안녕하세요, 싱글톤 레지스트리 부분 강의를 들으며 궁금한 점이 있어 질문드립니다. 웹 어플리케이션에서 상태값을 가지지않는 객체를 매번 생성하는 것이 메모리의 부족을 일으켜 성능이 저하된다는 말에 동의합니다. 제가 궁금한 것은 이것이 크게 효과가 있는것인지에 대해 궁금합니다. 그렇게 생각하는 이유는 @Component 어노테이션이 달린 클래스들(비즈니스 로직이 담긴 스프링빈) 은 많은 상황에서 DTO 를 반환하게되는데 해당 DTO 를 인스턴스화해서 반환하는 작업이 계속 수행되면 결국에는 큰 차이가 없지않나[복잡도로 봤을때 객체의 인스턴스를 생성하는 횟수는 같은 O(n) 이 아닐까..?] 하는 생각이 들어 질문하게 되었습니다. DB 커넥션을 맺는 DataSource 같은 빈이 아닌 어플리케이션의 비즈니스로직을 담은 빈을 싱글톤으로 다루는 것이 큰 효과가 있는지에 대해 답변을 부탁드립니다. 좋은강의 감사합니다.  

안녕하세요! 토비님, 제가 현재 JAVA와 DB를 공부하고 스프링으로 넘어가려고 합니다.다른 스프링 강의들은 구버전이던가 겉핥기 식 강의가 많은걸 후기로 많이 봤습니다.그래서 최신 버전이기도 하고 수강평에 초보자가 들어도 괜찮다해서 스프링 입문을 토비님 강의로 시작하려하는데 괜찮을지 고민이되네요,,!

모든 강의를 듣고 따라하면서 재미나게 실습했습니다.그 중에서롤백테스트할 때jakarta.transaction.Transactional또는org.springframework.transaction.annotation.Transactional의@Transactional만을 사용하면 정상동작합니다. 그런데,org.springframework.transaction.annotation.Transactional@Transactional(readOnly = true)readOnly = true 를 사용하여 테스트를 하면 insert 가 진행되지 않을 것을 예상했는데 진행이 되었습니다.왜 그런지 궁금합니다. 그리고,인프런안의 Kotlin 강좌중 추천할만한 강의가 있을까요?어제 유튜브에서 최근의 건강에 대해서 언급하셨는데,건강하고 늘 행복하게 보내세요.