클라이언트에서 서버에 요청을 하면 응답이 된다. 이때 WAS 에서 Servlet 을 호출하게 되는데 쓰레드가 바로 이 역할을 맡게된다. 쓰레드는 애플리케이션 코드를 하나하나 순차적으로 실행하게 되는데 자바 메인 메서드를 처음 실행하면 main이라는 이름의 쓰레드가 실행된다. 쓰레드가 없다면 자바 애플리케이션은 실행이 불가능하며 한 번에 하나의 코드 라인만 수행 할 수 있다. 또 동시 처리가 필요하다면 쓰레드를 추가로 생성하게 된다. 하나의 쓰레드만 있다고 가정할 때 요청이 오게 되면 쓰레드가 할당 된후 요청을 보내면 된다. 다중 요청일 경우 먼저온 요청을 처리 한 후 응답을 보내고 다음 요청을 수행하면 되지만 첫 번째 요청이 지연될 경우 두번 째 요청을 실행할 수 없을 뿐더러 첫 번째 요청까지 수행이 불..
실무에선 조건에 따라 실행되는 동적 쿼리가 많이 사용 된다. 복잡해져서 답 없는 미친 쿼리들을 작성하지 않기 위해 QueryDSL을 이용해보자. 우선 설정정보의 디펜던시에 querydsl을 추가 한다. dependencies { implementation 'com.querydsl:querydsl-jpa' implementation 'com.querydsl:querydsl-apt' } def querydslDir = "$buildDir/generated/querydsl" querydsl { library = "com.querydsl:querydsl-apt" jpa = true querydslSourcesDir = querydslDir } gradle 에서 compileQuerydsl을 활성화 시키면 새로운..
기존 필터가 수명을 다해서 어떤 필터를 사용해야 될 지 고민하다 바텀리스 포터필터로 교체했다. 와.. 커피맛이 너무 다르다. 풍미가 너무 깊다. 분명 이전 필터도 처음 사용했을 때는 저렇게 괜찮았을 텐데 너무 오래 사용하다 보니 필터 안쪽에 커피찌꺼기가 쌓여서 제대로 추출이 안됬었던것 같다. 바텀리스는 커피 찌꺼기가 쌓일 일도 없어서 너무 편하다 아주 만족스럽다
query를 날릴 때 distinct 사용시 페이징 처리를 할 수 없다는 단점이 있다. 대신 개 빠름. 그럼 페이징 처리를 하기 위해선 어떤 방식으로 해결 할 수 있을까? 우선 Order 라는 클래스가 아래와 같이 정의 되었다고 할 때 class Order{ private Long orderId; private Member member; private Delivery delivery; private List items; } Order 페이징 처리정보를 받아오기 위해선 distinct를 사용해서 아래와 같이 query를 날리면 된다. public List findAllOrders() { return em.createQuery( "select distinct o from Order o" + " join fe..
프로젝트시 매번 쿼리를 날릴 때 어떤 방식으로 쿼리를 작성해야지 좀 더 효율적으로 할 수 있을 지 고민했는데 아래와 같은 기준으로 정해서 사용하면 될 것 같다. 1. 엔티티 Dto 변환 (요거는 내 생각에 권장아니고 무조건 필수임) -> 엔티티를 외부에 노출 안하는게 좋은 코드작성 2. 필요하면 페치 조인으로 성능 최적화(대부분의 성능 이슈가 해결이 된다고 함) -> 엔티티 매니저에서 creatQuery를 통해서 직접 작성 List tests = entityManager.createQuery("select t from Test t" +" join fetch t.friend fr " +" join fetch t.family fa", Test.class) .getResultList(); 3. 직접 Dto로 ..
List 형식으로 반환 할 때 유연성 있게 class를 통해서 반환하자 class로 감싸서 반환하는것이 좀더 질 좋은 코드 @GetMapping("경로") public Result test(){ List findTests = testService.findTests(); List collect = findTests.stream() .map(t -> new TestDto(t.getName())); .collect(Collectores.toList()); return new Result(collect); } @Data @AllArgsConstructor static class Result{ private T data; }
@PostMapping을 이용해서 수정해도 괜찮지만 @PutMapping을 이용해서 만들자 @PutMappint("update/{id}") public void UpdateResponse( @PathVariable("id") Long id, @RequestBody @Valid Test test){ //내용 부분 } url에 수정할 데이터의 key 값인 id를 받아오고 수정 내용을 json 형식으로 받아오는 이런 방식을 사용해서 데이터를 수정한다.
실무 프로젝트를 진행할 경우 운영 시스템에서 System.out.print() 와 같은 시스템 콘솔을 사용해서 출력하지 않고 별도의 로깅 라이브러리를 사용해서 로그를 출력해야 한다. 스프링 부트 라이브러리를 사용하면 스프링 부트 로깅 라이브러리 spring-boot-starter-logging 가 함께 포함이 된다. 스프링 부트 로깅 라이브러리는 SLF4J, Logback의 라이브러리를 사용한다. 테스트 로그가 출력되는 포맷을 확인한다. 시간, 로그 레벨, 프로세스 ID, 쓰레드 명, 클래스 명, 로그 메세지 로그 레벨 설정을 변경해서 출력 할 수 있다. Level : trace > debug > info > warn > error
기존의 Servlet, JSP 같은 경우 너무 많은 역할을 수행한다. 비즈니스 로직과 뷰 렌더링을 다 처리하게 되면 너무 많은 역할을 하고 결과적으로 유지보수가 어려워진다. 따라서 각각의 역할을 나눠서 코드를 작성하는 MVC 패턴을 사용하게 된다. * 사실 가장 중요한 이유는 UI를 변경하는 일과 비즈니스 로직을 변경하는 일은 다른일이기 때문에 하나의 코드로 관리해서는 안된다. 컨트롤러 : HTTP 요청을 받아서 파라미터를 검증하고 비즈니스 로직을 실행하고 뷰에 전달할 결과 데이터를 조회후 모델에 담는다. 모델 : 뷰에 출력할 데이터를 담아둔다. 뷰 : 모델에 담겨있는 데이터를 사용해서 화면을 그리는 일에 집중한다.
웹 시스템 구성 정적 리소스는 웹 서버가 처리 하고 애플리케이션 로직같은 동적인 처리가 필요하면 웹 애플리케이션 서버에 요청을 위임 하게 되는 형식으로 많이 설계가 되고 있다. 또 이런방식의 설계는 효율적인 리소스를 관리하는데 많은 도움이 된다. 정적 리소스가 많이 사용되면 웹 서버를 증설하고 애플리케이션 리소스가 많이 사용되면 웹 애플리케이션 서버를 증설하면 된다. 또 이러한 설계는 웹 애플리케이션 서버가 오류를 발생했을 경우 웹 서버에서 오류 화면을 제공할 수 있다. (기본적으로 정적 리소스를 제공하는 웹 서버는 오류의 확률이 적다) Servlet 서블릿 HTTP 요청이 오면 웹 애플리케이션 서버는 Request, Response 객체를 새로 만들어서 서블릿 객체를 호출한다. 개발자는 Request ..
