Java Eco

이번에도 전편의 인기에 의해 불려나온 후속편이다. 지난번 아무것도 모르던 시절, 아파치의 commons-io 를 활용해 CommonsMultipartResolver 로 구현했다. 이번에는 스프링의 MultipartFile 를 이용해 파일 업로드 기능을 구현해보겠다 (현재 개인 프로젝트에 이 방식을 사용중) 아울러 김영한 강사님의 스프링 MVC 강의에 이같은 내용이 많기 때문에 이번에는 파일을 서빙하고 저장하고 관리되는 관점에서 글을 더 풀어보겠다. 이 글을 작성하는 시점에서 스프링6가 정식으로 나와있는데 아파치의 commons-io

🫠 실패에 대한 짧은 결론 : 레디스는 인메모리 DB로써 빠른 IO를 요구하는 작업에 최적화 되어있다. 예를 들면 세션 클러스터링이나 캐싱에 많이 사용된다. 그러나 Entity를 계층 구조로 만들고 깊은 내부의 있는 필드에 Document나 RDB 하듯 LIKE 쿼리를 구현하는 것은 바람직하지 않아보인다. 물론 단순한 구조의 Entity에 id필드를 지정하고 id를 가지고 직렬화/역직렬화 하는 것은 가능하다. 결론적으로 key로 value에 바로 접근할 수 있는 Set이나 Hash구조 일 때 의미가 있어보인다. 웹 기반의 채팅 프

TDD란 무엇인가? 를 떠나서 스프링 프로젝트에서 TDD를 어떻게 진행하는지에 대한 정리. TDD는 기본적으로 테스트 코드를 빌드업 해가면서 개발함. 즉, 이미 한참 완성된 코드를 테스트 하는건 TDD의 방향이 아님. 이런 경우는 있을까? 서비스 로직을 먼저 POJO로 만든다. 테스트 할 로직을 우선으로 만들면서 서비스 클래스, 엔티티, 영속성 클래스를 만든다. 서비스 로직에서 필요한 메서드, 클래스 등은 이너클래스로 먼저 개발 한 뒤 테스트가 완료되면 IDE를 통해 리팩토링 기능으로 꺼낸다. (IntelliJ → Move Inne

테이블과 객체의 연관관계에 대한 패러다임의 차이가 있다. 테이블은 연관관계라고 할 만한 것이 없다 (constraint 제외) 테이블간 연관관계가 필요하면 JOIN을 통해 관계를 갖는 방법 뿐이다. 반면 객체는 참조용 필드가 있으면 그쪽으로 참조가 가능하다. 클래스 내 멤버의 참조를 통해 이뤄진다. 이를 통해 양방향과 단방향 모두 관계를 정립할 수 있다. 테이블은 외래 키 하나로 두 테이블이 연관관계를 맺는다. 객체는 양방향 관계가 필요할 경우 양 객체에서 각각 참조가 필요하다. 외래키를 들고있는 쪽이 연관관계의 주인. 이것은 다(

웹 어플리케이션을 위한 Spring MVC (블로킹)과 Spring WebFlux(넌블로킹) 방식이 있음 물론 Spring MVC안에서도 @Async 어노테이션으로 비동기 처리를 활성 할 수 있으나 Filter, Interceptor 자체가 동기 처리라 엄청난 성능 향상은 없음 Spring WebFlux에도 Spring MVC와 마찬가지로 @Controller 어노테이션이 있있음. Spring MVC와 큰 차이라면 스트림을 위해 반환에 Mono, Flux를 사용. Spring MVC 는 톰캣 서블릿을 사용하는 프레임워크 고 WebF

용법 : <T, R> R method(T t) 제네릭 메소드는 매개 타입과 리턴 타입으로 타립 파라미터를 갖는 메소드를 말한다. 제네릭 메소드를 선언하는 방법은 리턴 타입 앞에 <> 기호를 푸가하고 타립 파라미터를 기술한 다음, 리턴 타입과 매개 타입으로 타입 파라미터를 사용하면 된다. 제네릭 메소드는 두 가지 방식으로 호출 할 수 있다.

어노테이션 기반의 컨트롤러, @RequestMapping을 처리하는 HandlerAdapter. 어노테이션 기반의 컨트롤러는 다양한 파라미터를 사용할 수 있다. (HttpServletRequest, Model, @RequestParam, @ModelAttribute, @RequestBody) 이것을 처리할 수 있는 것은 ArgumentResolver기반에서 작동하기 때문이다. 원하는 ArgumentResolver를 만들수도 있다. 컨트롤러의 반환 값을 변환 (ModelAndView, ResponseBody, HttpEntity..)

Reference 일단 오류와 상관없이.. SimpleJdbcInsert를 빈으로 만드는건 뭔가 이상한듯 저게 저 Repository에서만 쓸텐데.. 저걸 빈으로 만들어서 얻는 이점이 없음 JDBC 드라이버에서 제공해주는 DB 메타데이터를 사용해서 insert 쿼리 정보로 사용한다던데 왠지 빈으로 등록 시점에 JDBC 연결이 완료되지 않았을수도 있겠다 여튼, Entity 객체에서 리플렉션으로 '타입'정보를 꺼내쓴다면 애초에 dataSource같은게 필요없겠지 (순수 Java 리플렉션만으로 될테니) 근데 DataSource를 요구한다