BackEnd/spring (25) 썸네일형 리스트형 [코프링] coroutine 환경 Cache 적용 코프링 coroutine 환경에서 캐시 적용하기 위해 삽질을 하여 관련 내용을 기록 기존 spring web mvc와 동일한 방법으로 적용 캐시는 caffeine 적용하기로 하여 관련 종속 추가 implementation("org.springframework.boot:spring-boot-starter-cache") implementation("com.github.ben-manes.caffeine:caffeine") 설정 추가 @Configuration @EnableCaching class CacheConfig { @Bean fun cacheManager(): CacheManager { val caches: List = Arrays.stream(CacheType.values()) .map { cache .. [R2DBC] - Spring Data R2dbc Save Insert 이슈 해결 User.kt @Table("user") data class User ( @Id @Column("user_id") var userId: String = "" @Column("user_name") var userName: String = "" ) UserRepository.kt @Repository interface UserRepository : CoroutineCrudRepository { } userRepository.save(User(userId=“door”, userName=“ddori”)) 이슈 위처럼 spring data r2dbc를 이용하여 User를 insert 하려하면 기대와 다르게 update 쿼리가 발생한다. @Id 컬럼이 auto increment이면 이슈는 없지만 그렇지 않을경우 r.. R2DBC Oracle driver 연결 처리 r2dbc로 mysql은 쉽게 연결이 되었는데 막상 오라클 연결 할일이 있어 연결하니 쉽게 처리가 되지 않고 구글링에서도 정보가 잘 나오지 않아 정리한다. mysql driver build.gradle.kts implementation("dev.miku:r2dbc-mysql") application.yml spring: r2dbc: url: r2dbc:mysql://localhost:3306/scoregame_dev?serverTimezone=Asia/Seoul&characterEncoding=UTF-8 username: username password: password pool: enabled: true initial-size: 1 max-size: 1 oracle driver build.gradle... [Book] 인커밍 포트에 대한 의견 만들면서 배우는 클린 아키텍쳐 : 자바 코드로 구현하는 클린 웹 애플리케이션 내용 발췌 인커밍 포트는 애플리케이션 중심에 접근하는 진입점을 정의한다. 이를 제거하면 특정 유스케이스를 구현하기 위해 어떤 서비스 메소드를 호출해야할지 알아내기 위해 애플리케이션의 내부 동작에 대해 더 잘 알아야 한다. 전용 인커핑 포트를 유지하면 한눈에 진입점을 식별할수 있다. 이는 새로운 개발자가 코드를 파악할 때 특히 더 도움이 된다. 인커밍 포트를 유지해야 하는 또 다른 이유는 아키텍처를 쉽게 강제 할수 있게 때문이다. 인커밍 어댑터가 애플리케이션 서비스가 아닌 인커핑 포트만 호출하게 할수 있다. 그럼 어플리케이션 계층에 대한 모든 진입점을 정의하는 것이 아주 의식적인 결정이 된다. 인커밍 어댑터에서 호출할 의도가 없던.. 조회 전용 기능과 응용서비스와의 관계 논의 회사에서 개인적으로 CUD를 위한 조회가 아닌 화면에 보여주기 위한 조회 서비스는 사용자 또는 관리자의 요청으로 자주 항목들이 변경이 된다 그항목 하나 추가건으로 테이블 조인도 바끼고 많은 변화가 생길수 있다 대부분 도메인이 물리지 않고 여러 테이블을(다른 도메인의 테이블 포함) 조인해서 쿼리로 어떻게 보여주느냐로 결정 된다 위와 같은 조회 쿼리는 조회전용 DAO 만들어서 구현하였다 문제는 해당 DAO를 응용서비스에 종속관계를 두고 표현객체가 다시 응용서비스를 종속관계를 맺냐는 부분이다. 개인적으로 회사 및 토이 프로젝트에서는 표현객체에 바로 조회 전용 DAO를 사용하였다 해당 부분은 아직도 고민이 많은 부분으로 "도메인 주도 개발시작하기" 2022 재출간 본에 아래와 같은 이유로 표현객체에 조회전용 D.. 표현 영역 , 응용역역의 값 검증 논의 기본적으로 표현 영역에서 필수값과 값의 형식을 검사하고 실직적으로 응용 서비시는 ID 중복 여부와 같은 논리적 오류만 검사하면 된다. 즉 표현 영역과 응용 서비스가 값 검사를 나눠서 수행하는 것이다. 표현영역 : 필수값, 값의 형식, 범위등을 검증 응용서비스 : 데이타의 존재 유무와 같은 논리적 오류를 검증 논의 대상 응용 서비스에서 얼마나 엄격하게 값을 검증해야하는지 의견이 갈리수 있다 응용 서비스의 완성도를 높이기 위해서는 응용서비스에서 필수값 검증과 논리적인 검증을 모두 처리하면 표현영역에서 프레임워크가 제공하는 검증기능을 수행할때보다 작성할 코드가 늘어나는 불편함이 있지만 반대로 응용 서비스의 완성도가 높아지는 이점이 있다 이점이 더 크게 느껴진다고 생각하면 응용 서비스에서 값 오류를 검증하는 편.. 도메인 구현과 DIP 구현 기술에 대한 의존 없이 도메인을 순수하게 유지하려면 스프링 데이타 JPA의. Repository 인터페이스를 상속받지 않도록 해야하며 인터페이스를 도메인에 두고 구현한 클래스를 아래 그림과 같이 인프라에 위치 시켜야 한다. DIP를 적용하는 주된 이유는 저수준 구현이 변경되더라도 고수준이 영향을 받지 않도록 하기 위함이다. 하지만 리포지터리와 도메인 모델의 구현 기술은 거의 바뀌지 않는다. 저자는 JPA로 구현한 리포지터리 구현기술을 마이바티스나 다른기술로 변경한적이 없고, RDMS를 사용하다 몽고DB로 변경한 적도 없다고 한다. 이렇게 변경이 거의 없는 상황에 변경을 미리 대비하는것은 과하다고 생각한다. 그래서 저자는 에그리커트, 리포지터리등 도메인 모델을 구현할때 타협을 했다. JPA 전용 에너.. [이슈 해결] JPA save 와 Stomp 메세지 처리 이슈 Case Stomp를 이용한 채팅 구현시 Spring Data Jpa의 save를 통해 데이터 저장후 SimpMessageSendingOperations convertAndSend 메소드를 통한 메세지 발행시 저장된 데이타를 Front에서 조회시 간헐적으로 못가져오는 이슈 FLOW 1. [Front] 채팅서버에 Join 메세지 전송 2. [채팅서버] Join 정보 저장 및 접속 유저에 Join 메세지 발행 3. [Front] Join 정보 구독 발생에 따른 join 정보 채팅창에 메세지 처리 4. [Front] Join 정보 Api 호출 을 통한 접속자 부가 정보 화면에 노출 소스 코드 @Transactional fun joinByRoom(@Payload message: ChatMessageDto) { .. 이전 1 2 3 4 다음
