oceanflow 님의 블로그

Spring 프레임워크에서 @Transactional은 데이터베이스 트랜잭션을 관리하는 도구입니다. 하지만 이 어노테이션을 사용할 때 주의해야 할 함정 중 하나가 바로 자기 호출(Self-Invocation) 문제입니다. 이번 글에서는 이 이슈가 무엇인지, 왜 발생하는지, 그리고 어떻게 해결할 수 있는지 알아보겠습니다.@Transactional의 동작 원리Spring의 @Transactional은 AOP(Aspect-Oriented Programming)를 기반으로 동작합니다. Spring은 @Transactional이 붙은 메서드를 프록시 객체로 감싸서 트랜잭션 시작과 종료를 관리합니다. 즉, 메서드가 호출될 때 프록시가 개입하여 트랜잭션을 열고, 메서드 실행이 끝나면 커밋 또는 롤백을 처리합니다.하지..

@RestController@RequiredArgsConstructorpublic class MenuController { private final MenuService menuService; @PostMapping("/stores/{storeId}/menus") public ResponseEntity save(@PathVariable Long storeId, @Valid @RequestBody CreateMenuRequestDto dto) { return new ResponseEntity(menuService.save(dto, storeId), HttpStatus.CREATED); } @PutMapping("/stores/{storeId}/menus/{menuId..

과제인 코드 개선 퀴즈를 풀었다.Validation으로 코드를 개선하는 것이었는데 비밀 번호의 제약을 서비스의 해당 API가 아닌 DTO에서 처리하도록 만드는 것이었다.@Pattern 어노테이션을 사용하여 해결하였다.N+1 문제를 해결하는 문제도 있었는데 이는 @EntityGraph를 통해 해결하였다.또한 테스트 코드 연습 문제도 풀었다.

1. 서비스 간 의존성과 레포지토리 직접 의존의 판단 기준(1) 비즈니스 로직의 복잡성 레포지토리 직접 의존 적합한 경우: 단순 CRUD 작업 (예: findById()로 엔티티 조회만 필요할 때) 장점: 불필요한 계층을 거치지 않아 성능 최적화 가능, 코드 간결성 유지 서비스 간 의존 적합한 경우: 복잡한 비즈니스 로직 포함 (예: 조회 + 유효성 검증 + 이벤트 발행) 장점: 코드 재사용성 향상, 트랜잭션 관리 용이 2. 서비스간 의존성을 가질 때의 장단점 장점: 재사용성, 트랜잭션 관리, 관심사 분리, 테스트 용이성단점: 순환 참조, 결합도 증가, 테스트 복잡도 증가 추가로의존성 방향성 관리가 필요하다.서비스 A → 서비스 B → 서비스 C와 같이 단방향 의존성을 유지해야 순환 참조를 피할 수 있다..

HttpMessageConverter는 HTTP 요청과 응답의 데이터 변환을 처리하는 스프링 MVC의 핵심 기능이다.HttpMessageConverter는 HTTP Message Body의 내용을 읽거나 쓸 때 사용되며, 주로 JSON 데이터나 문자열을 처리할 때 활용한다. HttpMessageConverter가 적용되는 경우는 다음과 같다.1. HTTP 요청 : @RequestBody, HttpEntity, RequestEntity2. HTTP 응답 : @RequestResponse, HttpEntity, ResponseEntity요청과 응답 모두 사용된다. Spring은 다양한 HttpMessageConverter를 제공하고 있으며 우선순위가 있다.대상 Class와 MediaType을 체크하여 어떤 ..

오늘로써 일주일의 뉴스피드 프로젝트가 끝났다. 팀장을 맡았지만 미흡한 부분이 많았던 것 같다. 하지만 팀장을 맡아 배운점도 많았다. 깃 허브에 오거나이제이션을 구성하는 방법이나 팀으로 할때 깃 허브를 어떻게 사용하는지 머지나 그 외에 규칙을 어떻게 설정하는지 또한 팀장으로써 미리 어떠한 부분을 신경쓰고 이끌어야 할지 팀원들의 의견 조율은 어떻게 할지에 대해 조금이라도 감을 느낄 수 있는 프로젝트였던 것 같다.또한 개인 분담을 통해 진행한 부분에서도 API를 구성할 때 URI의 통일성이나 서비스에서 다른 서비스를 의존할 지 아니면 레파지토리에 의존할지에 대한 고민, 테이블의 구성, JWT의 활용법 등에 대해 알아갈 수 있는 시간이었다.

과제 진행 시에 메서드와 필드의 이름을 지을때 그때 그때 생각해서 짓지 말고 일관성있게 지어야 하며 막무가내로 진행하다보면 필드명이나 메서드명이 달라 어디서 충돌 및 막히는지 알 수 없어 크게 보고 개발을 진행 해야겠다는 교훈을 얻었다.위의 문제가 있어 시간이 많이 걸렸다. 어디서 문제가 생긴지 알 수 없어서였다. 오류 메시지는 따로 나오지 않았고 계속 실행이 안되었다. 또한 세션으로 로그인 기능을 넣었는데 검색을 해보니 세션에 타임아웃 설정을 해주어 세션을 관리해주어야 한다고 하는데관련해서 더 공부를 해야겠다고 느꼈다. 또한 로그인을 하였으면 그를  통해 사용자를 인증하고 CRUD를 해야하는데 그런 기능을 넣지 못해서 아쉽다. 아직 구현하는데 미숙함이 있어 시간이 오래 걸리는 것 같다.

IOC(제어의 역전)객체의 생성과 관리 권한을 개발자가 아닌 스프링 컨테이너가 담당하는 것을 말한다.기본적으로는 개발자가 객체를 직접 생성하고 관리했지만, 스프링에서는 컨테이너가 객체 생성,주입, 소멸을 관리한다. IOC의 장점은 다음과 같다.객체간의 낮은 결합도코드의 재사용성 증가유지보수의 용이성테스트 용이성 향상 DI(의존성 주입)스프링이 객체 간의 의존성을 자동으로 주입해주는 것을 의미한다.한 객체가 다른 객체를 사용할 떄, 해당 객체를 직접 생성하지 않고스프링이 주입해주는 방식이다.IOC를 구현하는 방식 중 하나 의존성 주입 방법 1. 생성자 주입(권장)객체 생성 시점에 의존성을 주입불변성 보장과 필수 의존성 명시 가능 2. 세터 주입선택적 의존성을 주입할 때 사용런타임에 의존성 변경 가능 3. ..

SOLID 원칙은 객체 지향 설계의 5가지 기본 원칙이자 소프트웨어 설계에서 유지보수성, 확장성, 유연성을 높이기 위한 지침이다. SOLID에는 단일 책임 원칙, 개방 폐쇄 원칙, 리스코프 치환 원칙, 인터페이스 분리 원칙, 의존관계 역전 원칙이 있으며각 원칙의 영문 첫 글자를 조합하여 만든 단어이다, Single Responsibility Principle (S), Open-Closed Principle (O), Liskov Substitution Principle (L), Interface Segregation Principle (I), Dependency Inversion Principle (D) 단일 책임 원칙하나의 객체는 하나의 책임만 가져야 한다. 개방 폐쇄 원칙소프트웨어 엔티티(클래스, 모듈..

오늘은 schadule project를 마무리하고 schadule project에 대한 과제 해설을 들었다.과제를 진행하며 강의를 듣고 과제를 진행해야 하는데 강의의 내용을 이해하기에 어려움이 있었고또한 설이라는 명절이 있어 공부에 있어 집중하지 못한 것 같다. 오늘부터 다시 마음을 다잡고 공부를 해야 겠다.필수 과제는 진행하였으나 아쉬운 점이 많았다. 오늘 푼 알고리즘은 이다. 두 정수 a,b가 주어졌을 때 a와 b 사이에 속한 모든 정수의 합을 리턴하는 함수, solution을 완성하세요.예를 들어 a = 3, b = 5인 경우, 3 + 4 + 5 = 12이므로 12를 반환하게된다. 처음에는 a와 b를 비교하여 큰 수를 찾아 for문을 돌려 해결하려 하였으나더 간결한 방법을 찾아 내었다.등차 수열의 ..