서비스에 적용하는 @Valid는 사용을 위해서 클래스에 @Validated를 붙어주었는데? 컨트롤러에는 @Valid만 사용하셨습니다? 서비스와 같이 @Validated를 붙여줘야 하는것 아닌가요? 서비스와 컨트롤러의 사용방법 차이에 대해서 궁금합니다. --- 정확하게는 모르지만 검증 주체의 차이로 달라지는 것으로 알고 있습니다.
강사님께서는 단순히 "프로젝트 구조를 알려줘" 라고 입력하셨는데도 응답이 제대로 나오는데, 제가 입력하면 "폴더를 찾을 수 없습니다. 현재 작업 디렉토리의 절대 경로를 제공해주시거나, 프로젝트의 루트 디렉토리 경로를 알려주시면 해당 폴더 구조를 보여드리겠습니다." 이런식으로 나오고 있습니다. 코드는 자료에 나온 그대로 작성했는데 경로를 제대로 못찾는 이유를 모르겠네요;;
안녕하세요. 요새 조회 메서드 네이밍 컨벤션에 대해 고민 중인데요. Repository 계층을 제외한 애플리케이션, 도메인 등 계층에서 조회(DB 조회 아닌 경우도 포함) 관련 메서드 명를 작성할 때 네이밍 컨벤션에 대해 고민 중입니다. find를 쓰자니 Spring Data 관례인거 같아 이외 계층에서도 꼭 이렇게 사용할 필요가 있을거 같기도 해서 어떤 방식이 좋을지 조언을 듣고 싶습니다. 현재 생각 중인 3가지 네이밍이에요. 앞에 있는게 데이터가 없을시 예외가 발생하는거고, 뒤에가 없으면 null(또는 Optional) 반환입니다. get / find getOrThrow / get get / getOrNull
질문 시에는 위 내용은 삭제하고 다음 내용을 남겨주세요. ========================================= [질문 템플릿] 1. 강의 내용과 관련된 질문인가요? (예/아니오) 2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? (예/아니오) 3. 질문 잘하기 메뉴얼을 읽어보셨나요? (예/아니오) [질문 내용] 강의의 fieldInjectionTest() 에서는 new OrderServiceImpl() 로 객체를 직접 생성하는데, 이 경우 스프링 컨테이너를 거치지 않으므로 @Autowired 필드 주입이 실행되지 않는 것 아닌가요? 그렇다면 이 테스트는 필드주입의 단점을 보여주는 테스트가 아닌것 같아서요..
질문 시에는 위 내용은 삭제하고 다음 내용을 남겨주세요. ========================================= [질문 템플릿] 1. 강의 내용과 관련된 질문인가요? (예/아니오) 2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? (예/아니오) 3. 질문 잘하기 메뉴얼을 읽어보셨나요? (예/아니오) [질문 내용] 컴포넌트 스캔과 의존관계 자동 주입 시작하기 강의에서 AutoAppConfig를 만든 이유는 단지 테스트 빈을 가져오기 위한 설정정보를 넘기기 위해서인가요? 컴포넌트 스캔과 자동 주입을 활용할 경우 Config 클래스가 특별한 상황이 아닐 경우 필요가 없을 것 같은데, 맞을까요?
이거 6버전으로 읽고 있다가 문득 이상해서 질문남긴다. RunIdIncrementer <- 이거 지금 5랑 6랑 동작.. 완전 다른거 같은데 맞냐..? (완전 다르다기 보다, 스프링 배치 리드의 이슈에서는 너네가 잘못 쓰고 있던거다 라고 하긴하던데) 전에는 같은 파라미터로 재시작할때도 사용가능했는데, 이제는 이거 안바꾸고 버전업하면 "하위고과" 확정이다.
질문 시에는 위 내용은 삭제하고 다음 내용을 남겨주세요. ========================================= [질문 템플릿] 1. 강의 내용과 관련된 질문인가요? 예 2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? 예 3. 질문 잘하기 메뉴얼을 읽어보셨나요? 예 [질문 내용] AppConfig의 경우 객체 설정 정보들을 직접 작성해서 설정하는 객체로 이해를 했습니다. 근데 이전에 스프링 빈 관련해서 학습할 때 '스프링 빈으로 등록이 되면 스프링이 알아서 객체를 만들어서 주입을 해준다' 라고 정리를 했었거든요. 그럼 여기서 굳이 AppConfig를 사용하는 이유는 단순히 여러 구현체들을 바꿔가면서 사용할 수 있기 때문인가요? 스프링 빈의 경우 여러 구현체가 등록이 되면 스프링이 자동 생성할 때 어떤 구현체를 사용할 지 몰라서 컴파일 에러가 난다고 알고 있습니다.(물론 특정 어노테이션을 통해서 해결 가능하지만) 스프링빈을 통해서 자동 생성 및 주입이 가능한데, AppConfig가 왜 필요한지, 무슨 차이인지 궁금합니다!
안녕하세요! 강의를 열심히 듣다가 돌연 멀티 모듈이라는 주제로 생각하다가 질문을 남깁니다! 현재 강의에서는 application 레이어에서 repository를 가지고 있는데요! 멀티 모듈로 설계 시에도 동일하게 application 레이어에 repository를 가지는 게 일반적인가요? 검색을 하거나 하면 adapter에 persistence 쪽이나 infra 레이어 쪽에 가지고 있어야 한다는 내용이 보이는거 같아서요. 토비님께서는 어떻게 생각하시는지 궁금합니다! 또한, 보통 멀티 모듈로 프로젝트를 구성하실 때 어떤 방식으로 접근하시는지도 궁금합니다! 긴 글 읽어주셔서 감사합니다.
네카라쿠배 시니어의 실무 하네스 엔지니어링 : 실전 Spring Boot 환경에서 사용하는 클로드 코드
7. 클로드코드 명령어 - 대화&세션관리 - windows 기본 압축풀기 실행 : 압축풀기를 완료할 수 없습니다. 라는 오류 메시지 - Alzip : html 파일명이 "_녲뀱_솽꼨_㎭녅_뗡뀯-_뚡뀯_メ꼶_╇꼩_⒰넧_끷뀳__html"과 같이 깨져있음. 8. 클로드코드 명령어 - 모델&실행제어 - 자료 download 클릭시 아무 동작도 이루어 지지 않음 13,14,15,16도 동일하게 자료 download 클릭시 아무 동작도 이루어 지지 않음 17. [핵심실행] Java console 앱을 이용한 클로드코드 세팅하기 - 정상 다운로드, 정상 압축 풀기 다른 분들도 문제가 있다고 의견 올리고 있으니까 조금 더 확인 부탁드립니다.
[질문 템플릿] 1. 강의 내용과 관련된 질문인가요? 예 2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? 아니오 3. 질문 잘하기 메뉴얼을 읽어보셨나요? 예 [질문 내용] db연결을 close하는 부분에서 conn은 DataSourceUtils에서 왔기 때문에 releaseConnection을 통해서 커넥션을 끊어줘야 트랜잭션 도중 닫히는 문제를 막을 수 있다고 하셨는데요. 근데 그 close하는 함수 부분에서 throws SQLException을 던지셨던데요. utils함수의 releaseconnection함수를 보면 exception 던지지 않고 로그만 직던데요. throws 던질 이유가 있을까요? 저게 없으면 catch에서 에러가 표시되던데 무엇이 올바른지 모르겠습니다.
학습하는 분들께 도움이 되고, 더 좋은 답변을 드릴 수 있도록 질문전에 다음을 꼭 확인해주세요. 1. 강의 내용과 관련된 질문을 남겨주세요. 2. 인프런의 질문 게시판과 자주 하는 질문(링크)을 먼저 확인해주세요. (자주 하는 질문 링크: https://bit.ly/3fX6ygx) 3. 질문 잘하기 메뉴얼(링크)을 먼저 읽어주세요. (질문 잘하기 메뉴얼 링크: https://bit.ly/2UfeqCG) 질문 시에는 위 내용은 삭제하고 다음 내용을 남겨주세요. ========================================= [질문 템플릿] 1. 강의 내용과 관련된 질문인가요? (예/아니오) 2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? (예/아니오) 3. 질문 잘하기 메뉴얼을 읽어보셨나요? (예/아니오) [질문 내용] 수업자료 오타 현재 : 회원 관리용 홈 - resources/templates/hello.html -> to-be : 회원 관리용 홈 - resources/templates/home.html
안녕하세요. 커뮤니티 글도 참조하고 이클립스 재설치도 해봤지만 Window > Preferences > Add Remote Catalog.. 에서 아래 URL 지정시 New Maven Project에서 TOBESOFT에 아무것도 뜨지 않습니다. mangosteen.tobesoft.co.kr/nexus/repository/tobesoft-snapshots/archetype-catalog.xml 확인 부탁드립니다..
토비님 안녕하세요! 좋은 강의 만들어 주셔서 감사합니다. 객체지향 프로그래밍에서는 객체의 내부 구현이나 구조를 외부에서 직접 알 필요가 없도록 캡슐화하고, 객체의 행동을 통해 상호작용하는 것이 중요하다고 알고 있습니다. 기존 테스트에서는 Course 내부의 detail 객체에 직접 접근합니다. 이를 아래와 같이 수정해봤습니다. public class Course extends AbstractEntity { public LocalDateTime getPublishedAt() { return detail.getPublishedAt(); } } @Test void publish() { course.submitForReview(); course.publish(); assertThat(course.getStatus()).isEqualTo(CourseStatus.PUBLISHED); //assertThat(course.getDetail().getPublishedAt()).isNotNull(); assertThat(course.getPublishedAt()).isNotNull(); assertThatThrownBy(() -> course.publish()) .isInstanceOf(IllegalStateException.class); } 이러한 판단이 객체지향의 캡슐화, 정보 은닉 관점에서 올바른지 궁금합니다.