Skip to content

학습내용

Jump to bottom
YongHwan Kim edited this page Apr 9, 2023 · 42 revisions

목차

JSP vs Mustache vs Thymeleaf

Template Engine

  • 지정된 템플릿 양식과 데이터가 합쳐져서 html 문자를 만들어주는 소프트웨어입니다.
  • 프로그램 로직과 뷰 계층을 분리하기 위한 수단으로 사용됩니다.

서버 템플릿 엔진(SSR, Server Side Rendering)

  • 서블릿(서버)에서 동작하는 템플릿입니다.
  • 템플릿 양식과 데이터를 이용하여 동적인 html 파일을 생성하여 브라우저에 전달합니다.

클라이언트 템플릿 엔진(CSR, Client Side Rendering)

  • React, Vue, Anguler와 같이 서버에서 json 데이터를 전달받고 전달 받은 데이터를 기반으로 웹 페이지를 렌더링하는 라이브러리 혹은 프레임워크입니다.
  • SPA(Single Page Application) 환경으로 동작합니다.
  • 자바스크립트는 브라우저 위에서 실행되어 브라우저에서 실행될 때는 서버 템플릿 엔진의 손을 벗어나 제어할 수 없습니다.

Mustache

  • JSP와 같이 html을 만들어주는 템플릿 엔진입니다.
  • 로직 코드를 사용할 수 없기 때문에 View 역할과 서버의 역할을 명확히 분리하게 해줍니다.
  • Mustache.js와 Mustache.java 두가지가 존재하여 하나의 문법으로 클라이언트/서버 템플릿으로 모두 사용이 가능하게 합니다.

JSP vs Mustache

  • JSP는 Java 언어를 지원하고, Mustache는 Java는 물론, 대부분의 언어를 지원합니다.
  • JSP는 로직 구현이 가능하고, Mustache는 로직 구현이 불가능합니다. (View 역할에 충실합니다.)
  • JSP는 스프링부트에서 권장하지 않는 템플릿 엔진이고 Mustache는 스프링부트에서 공식으로 지원하는 템플릿 엔진입니다.

Mustache vs Thymeleaf

  • Thymeleaf는 Mustache에 비해서 문법이 어렵다는 단점이 존재합니다.
  • Thymeleaf는 Mustache에 비해서 좀더 복잡한 로직을 수행할 수 있습니다. 대신 View 역할에 집중하지 못할 수 있습니다.
  • Thymeleaf는 서버 사이드 템플릿 엔진을 수행할 수 밖에 없는데 비해 Mustache는 클라이언트/서버 템플릿 엔진으로 수행할 수 있습니다.

@RequestBody

HTTP 요청의 body에 담긴 데이터를 자바 객체로 변환해주는 역할을 수행합니다.

HTTP 요청의 Content-Type을 기반으로 자동으로 데이터 변환을 처리합니다. Content-Type이 application/json인 경우 JSON 데이터를 자바 객체로 변환합니다.

선택적으로 @Valid 애노테이션을 사용하면 HTTP 요청의 body에 담긴 데이터를 자바 객체로 변환한 후에, 해당 객체의 유효성을 검증할 수 있습니다.

Gradle 의존성 옵션

Gradle

  • 그래들(Gradle)은 그루비(Groovy)를 기반으로 한 빌드 도구입니다.
    • 그루비(Groovy) : 객체지향 프로그래밍 언어로 자바 플랫폼 상에서 동작하는 언어
  • And와 Maven같은 이전 세대 빌드 도구의 단점을 보완하고 장점을 취합하여 만든 오픈소스로 공개된 빌드 도구
    • And 단점
      • XML 기반 설정 방식으로 복잡한 빌드 로직을 구현하기 어렵습니다.
      • 의존성 관리가 어렵고, 라이브러리들을 수동으로 다운로드하여 라이브러리 경로를 추가해주어야 합니다.
      • 유연성이 떨어지며, 프로젝트 규모가 크고 복잡해질수록 유지보수가 어렵습니다.
    • Maven 단점
      • 빌드 시간이 오래 걸리는 경우가 있습니다.
      • 다른 빌드 도구에 비해 복잡한 설정 방식을 사용합니다.
      • 의존성 해결과 라이브러리 관리에 대한 이해가 필요합니다.
    • Gradle 장점
      • 선언적 문법 : 빌드 스크립트를 선언적인 방식으로 작성할 수 있습니다.
      • 멀티 프로젝트 지원 : 여러 프로젝트를 한번에 빌드할 수 있습니다. 이를 통해 프로젝트간 의존성 관리를 쉽게 할 수 있습니다.
      • 빌드 캐시 : Gradle은 빌드 결과를 캐시하여 빌드 시간을 줄일 수 있습니다.
      • 다양한 플러그인 지원 : 플러그인을 통해 빌드 스크립트를 간단하게 작성할 수 있습니다.
      • 스크립트 언어 : Gradle은 Groovy, Kotlin 등의 스크립트 언어를 지원하여 빌드 스크립트를 간결하게 작성할 수 있습니다.
      • 유연성 : 사용자의 요구에 맞게 빌드 시스템을 구성할 수 있습니다.

선언적 문법 예시

dependencies {
    implementation 'com.google.guava:guava:30.1.1-jre'
    testImplementation 'junit:junit:4.13.2'
}

멀티 프로젝트 지원 예시

root-project/
   build.gradle
   settings.gradle
   sub-project1/
       build.gradle
       src/
   sub-project2/
       build.gradle
       src/

settings.gradle 파일에 각 하위 프로젝트 정의
include 'sub-project1'
include 'sub-project2'

compile vs implementation

image 위 그림을 보면 모듈 B, C가 모듈 A에 의존하고 있는 그림입니다.

  1. compile을 사용하는 경우
  • A 모듈을 수정하게 되면 A 모듈을 의존하는 모듈 B, C도 같이 리빌드(rebuild)됩니다.
  • 간접적으로 의존하는 모듈까지 다시 빌드하게 되므로 시간이 오래 걸리게 됩니다.
  1. implementation을 사용하는 경우
  • A 모듈을 수정하게 되면 A 모듈을 직접적으로 의존하는 모듈까지만 리빌드됩니다.
  • 직접적으로 의존하는 모듈까지만 빌드하게 되므로 시간이 상대적으로 적게 걸립니다.
  • 사용자에게 필요 이상의 API를 노출하는 것은 불필요하므로 API의 노출을 막을 수 있습니다.

의존성 옵션들

  • implementation : 의존 라이브러리 수정시 본 모듈까지만 재빌드합니다.

    • 본 모듈을 의존하는 모듈은 해당 라이브러리의 api를 사용할 수 없습니다.
    • 본 모듈의 라이브러리가 api를 외부에 공개하지 않았거나 외부에서 api를 사용할 수 없는 제한이 있다는 의미입니다.
    • 예를 들어 A 모듈을 의존하는 B 모듈이 있고 B 모듈을 의존하는 C 모듈이 존재할때 A 모듈 수정시 B 모듈까지만 재빌드합니다. C 모듈은 A 모듈의 api를 사용할 수 없습니다.

  • api : 의존 라이브러리 수정시 본 모듈을 의존하는 모듈들도 재빌드합니다.

    • 본 모듈을 의존하는 모듈들도 해당 라이브러리의 api를 사용할 수 있습니다.
    • 예를 들어 A <- B <- C와 같이 A 모듈을 B,C 모듈이 의존한다고 가정할때 C 모듈이 A 모듈의 api를 사용할 수 있습니다.

  • compileOnly : compile 시에만 빌드하고 빌드 결과물에는 포함되지 않습니다. runtime 시 필요없는 라이브러리인 경우 사용하는 의존성 옵션입니다.

  • runtimeOnly : runtime 시에만 필요한 라이브러리인 경우 설정하는 옵션입니다.

  • annotationProcessor : 자바 컴파일러가 컴파일 시점에 애노테이션을 처맇라 때 사용되는 라이브러리나 모듈입니다.

    • 애노테이션을 사용하여 컴파일 시점에 코드를 생성하거나, 검증 등의 작업을 할 수 있습니다.
    • ex) lombok

  • testImplementation : 테스트할때만 사용하는 의존성 라이브러리 옵션입니다.

    • ex) junit, mockito

assertj의 assertThat이 junit의 assertThat보다 편리한 이유

junit의 assertThat 사용시 불편한 점은 다음과 같습니다.

  • 자동완성
    • allOf, greaterThan, lessThan, is 등의 메소드들을 미리 import 해놓지 않으면 IDE에서 자동완성을 해주지 못하기 때문에 필요한 메소드들을 공식문서에서 찾거나, 이름을 외워서 작성해야 합니다.
    • 즉, IDE에서 자동완성을 해주지 못하기 때문입니다.
  • Assertion 분류(matcher)
    • 원하는 matcher를 찾기가 불편합니다.
  • 확장성
    • 추가된 조건을 검증하기 위해서는 allOf와 같은 메소드로 기존 조건과 묶어주어야 합니다.
    @Test
    public void number_test() throws Exception {

        int number = 3;

        int result = mathService.add(number, 3)

        assertThat(result, allOf(
            greaterThan(0),
            lessThan(10)
        ));
    }

assertj의 assertThat 장점은 다음과 같습니다.

  • 자동완성
    • assertThat에서 반환되는 Assert 클래스를 사용하기 때문에 메소드 자동완성이 지원되어 편리합니다.
  • Assertion 분류
    • assertThat에서 인자의 타입에 맞는 Assert 클래스를 반환하기 때문에 필요한 메소드만 분류되어 있습니다.
  • 확장성
    • 체이닝 메소드 패턴으로 작성 가능하기 때문에, 조건 추가를 위해 추가 작업이 필요가 없어서 가독성이 좋습니다.
    @Test
    public void number_test() throws Exception {

        int number = 3;

        int result = mathService.add(number, 3)

        assertThat(result)
                .isGreaterThan(0)
                .isLessThan(10);

    }

ModelAndView 객체를 이용한 리다이렉트, 포워딩

@RequestMapping("/login")
public ModelAndView login(@RequestParam("username") String username, 
                           @RequestParam("password") String password) {
    if (isValidUser(username, password)) {
        return new ModelAndView("redirect:/home"); // 리다이렉트
    } else {
        ModelAndView modelAndView = new ModelAndView("login"); // 포워딩
        modelAndView.addObject("error", "Invalid credentials");
        return modelAndView;
    }
}

리다이렉트와 포워딩 비교

리다이렉트

  • 서버는 클라이언트에게 다른 URL로 이동하도록 요청을 보내고, 클라이언트는 새로운 URL로 GET 요청을 보내 페이지를 받아옵니다.
  • 리다이렉트 과정에서 클라이언트와 서버간에 새로운 HTTP 요청이 발생 하므로, URL이 변경됩니다.
  • 주로 로그인, 로그아웃, 회원가입 등에서 사용됩니다.

포워딩

  • 서버에서는 클라이언트에게 다른 페이지로 이동할 필요가 없게 합니다. 대신, 현재 요청된 페이지를 처리하기 위해 다른 페이지로 제어를 넘깁니다.
  • 클라이언트는 이전 URL을 유지한 상태로 새로운 페이지를 받아오기 때문에 URL이 변경되지 않습니다.
  • 포워딩 과정에서 추가적인 HTTP 요청이 발생하지 않으므로 , 보낼 데이터의 양이 많은 경우에도 URL이 길어지지 않습니다.

@RequestParam, @ModelAttribute, @RequestBody

@RequestParam

  • HTTP 요청 파라미터를 메소드의 인자로 받아오는 방법중 하나입니다.
  • 요청 파라미터의 이름과 매핑될 수 있는 메소드의 매개변수를 지정할 수 있습니다.
@RequestMapping("/hello")
public String sayHello(@RequestParam("name") String name) {
    return "Hello, " + name + "!";
}

위 예시에서 @RequestParam("name")은 "name" 파라미터의 값을 받아서 String name 변수에 저장합니다. 즉, "/hello?name=김용환" 요청이 들어오면 name 변수에는 "김용환"이 저장됩니다.

@RequestParam 수행과정을 코드로 표현하면 다음과 같습니다.

@RequestMapping("/hello")
public String sayHello(HttpServletRequest request) {
    String name = request.getParameter("name");
    return "Hello, " + name + "!";
}

@ModelAttribute

  • @ModelAttribute는 사용자가 요청시 전달하는 값을 객체 형태로 매핑해주는 애노테이션입니다.
  • 매핑받는 객체는 setter 메소드가 있어야합니다.
    @PostMapping("/users")
    public String create(@ModelAttribute User user) {
        logger.info(user.toString());
        return "index";
    }

위와 같은 코드가 있으면 Spring 내부적으로 다음과 같은 코드를 수행합니다. request는 HttpServletRequest 타입의 객체입니다.

User user = new User();
user.setName(request.getParameter("name"));
user.setAge(Integer.parseInt(request.getParameter("age")));
user.setEmail(request.getParameter("email"));
model.addAttribute("user", user);

@RequestBody

  • HTTP 요청 바디의 데이터를 자바 객체로 변환해줍니다.
  • 요청 바디에 JSON, XML, TEXT 등의 데이터를 자바 객체로 변환하여 컨트롤러 메소드의 파라미터로 전달할 수 있습니다.
{
    "name": "John",
    "age": 25,
    "email": "john@example.com"
}

@RequestMapping(value = "/user", method = RequestMethod.POST)
public ResponseEntity<String> createUser(@RequestBody User user) {
    // ...
}

DB_CLOSE_ON_EXIT

  • h2 데이터베이스 설정 옵션 중 하나입니다.
  • 이 옵션을 사용하면 DB 연결 종료시 데이터베이스가 자동으로 종료되지 않고 유지됩니다.
  • DB_CLOSE_ON_EXIT-FALSE를 설정하면 애플리케이션 종료시 데이터베이스가 자동으로 삭제되지 않고 유지됩니다. 따라서 애플리케이션을 다시 실행하면 이전에 생성된 데이터베이스를 사용할 수 있습니다.

JdbcTemplate를 사용하여 자동 생성 키를 얻기

String INSERT_MESSAGE_SQL 
  = "insert into sys_message (message) values(?) ";
    
public long insertMessage(String message) {    
    KeyHolder keyHolder = new GeneratedKeyHolder();

    jdbcTemplate.update(connection -> {
        PreparedStatement ps = connection
          .prepareStatement(INSERT_MESSAGE_SQL);
          ps.setString(1, message);
          return ps;
        }, keyHolder);

        return (long) keyHolder.getKey();
    }
}

AOP

AOP와 OOP의 관계

  • OOP 사용하는 이유는 비즈니스 로직의 중복을 제거하기 위함입니다.
  • AOP를 사용하는 이유는 인프라 로직의 중복을 제거하기 위함입니다.

비즈니스 로직이란?

  • 실세계의 데이터를 생성,표시,저장,변경하는 부분을 의미합니다.
  • 데이터의 상태 값을 조작하는 로직
  • 예를 들어 회원의 생성, 정보 변경, 삭제 등이 있습니다.

인프라 로직이란?

  • 핵심적인 비즈니스 로직은 건들이지 않으면서 성능을 높이고, 보안을 강화하기 위해 처리하는 로직
  • 권한 검사, 트랜잭션, 데이터 캐싱, 로깅, 성능 측정 등이 인프라 로직이 될 수 있습니다.

인프라 로직 특징

  • 인프라 로직은 프로그래밍 모든 영역에 걸쳐 등장합니다.
  • 많은 중복 코드를 양산합니다.
  • 코드 가독성을 떨어뜨리고, 유지보수를 어렵게 합니다.

AOP를 사용하는 이유

  • 인프라 로직의 중복을 제거하여 비즈니스 로직에 집중할 수 있도록 합니다.
  • AOP와 OOP는 적대관계가 아닌 상호 보완관계입니다.

Servlet Filter와 Intercepter

image

위 그림과 같이 DispatcherServlet 이전, 이후에는 CharacterEncodingFiler, ResourceFileter가 작동하는데 이 부분이 AOP 기능을 수행하고 있는 것입니다.

AOP 관련 용어들

  • target : 비즈니스 로직 수행 대상
  • advice : 비즈니스 로직을 수행하는 target에게 제공하는 부가 기능을 수행하는 클래스 (인프라 로직)
  • pointcut : 인프라 로직이 적용될 대상을 지정하는 것
  • joinpoint : 인프라 로직이 적용될 위치, 예를 들어 메소드의 실행 단계 등이 있습니다.

image

AOP 실습

// Aop는 빈으로 등록되어야함
@Aspect
@Component
public class TimeTraceAop {

    // 패키지명..클래스명(타입)
    // ex) "execution(* hello.hellospring.service..*(..)) 서비스 하위 패키지에만 시간 추적 aop 적용
    @Around("execution(* hello.hellospring..*(..))") // 공통 관심사항을 어디에 적용할 것인지 선택
    public Object execute(ProceedingJoinPoint joinPoint) throws Throwable {
        long start = System.currentTimeMillis();
        System.out.printf("START: %s%n", joinPoint);
        try {
            return joinPoint.proceed();
        } finally {
            long finish = System.currentTimeMillis();
            long timeMs = finish - start;
            System.out.printf("END: %s %dms%n", joinPoint, timeMs);
        }
    }

}

Spring Interceptor

  • Spring 프레임워크에서 제공하는 기능 중 하나로, 클라이언트의 HTTP 요청을 처리하기 전/후에 수행되는 기능을 구현할 수 있게 해주는 기능입니다.
  • Interceptor는 클라이언트 요청이 처리되기 전에 해당 요청의 정보를 가로채어 전처리 작업을 할 수 있고, 요청 처리 이후에는 응답 정보를 가로채어 후처리 작업을 할 수 있습니다.
  • 예를 들어 로그인을 해야하는 페이지에서 Interceptor를 사용하면 로그인 페이지에 입장하면 세션을 검증하고, 세션이 유효하지 않으면 로그인 페이지로 이동시키는 작업을 수행할 수 있습니다.

Spring Interceptor 구현방법

  1. HandlerInterceptor 인터페이스 구현
public interface HandlerInterceptor {
    // Controller 메소드 실행 전
    boolean preHandle(HttpServletRequest request,
        HttpServletResponse response, Object handler)
            throws Exception;

    // Controller 메소드 실행 후
    void postHandle(
            HttpServletRequest request, 
            HttpServletResponse response, 
            Object handler, ModelAndView modelAndView)
            throws Exception;

    // 클라이언트에 응답을 보낸 후
    void afterCompletion(
            HttpServletRequest request, 
            HttpServletResponse response, 
            Object handler, Exception ex)
            throws Exception;

}

ServletFilter와 Interceptor의 한계

  • ServletFilter는 Servlet 실행 전/후에 대한 처리, Interceptor는 메소드 실행 전/후에 대한 처리만 가능합니다.
  • 애플리케이션 전체 소스 코드에 대해 Aspect를 적용하고 싶다면 Spring AOP를 사용할 수 있습니다.

Interceptor 실습

  1. HandlerInterceptor 인터페이스 구현체 정의
public class PerformanceInterceptor implements HandlerInterceptor {

    private static final Logger logger = LoggerFactory.getLogger(PerformanceInterceptor.class);
    private static final String START_TIME = "START_TIME";

    @Override
    public boolean preHandle(HttpServletRequest request, HttpServletResponse response,
        Object handler) throws Exception {
        request.setAttribute(START_TIME, System.currentTimeMillis());
        return true;
    }

    @Override
    public void postHandle(HttpServletRequest request, HttpServletResponse response, Object handler,
        ModelAndView modelAndView) throws Exception {
        long startTime = (long) request.getAttribute(START_TIME);
        logger.info("execution time : {}", System.currentTimeMillis() - startTime);
    }
}
  1. 설정 파일 클래스를 만들고 WebMvcConfigurer 인터페이스를 구현합니다. 그중에서 addInterceptors 메소드를 재정의합니다. 또한 performanceInterceptor 빈도 생성합니다.
@Configuration
@EnableWebMvc
@ComponentScan(basePackages = {"hello"})
public class SpringConfig implements WebMvcConfigurer {

    @Bean
    public PerformanceInterceptor performanceInterceptor() {
        return new PerformanceInterceptor();
    }

    @Override
    public void addInterceptors(InterceptorRegistry registry) {
        registry.addInterceptor(performanceInterceptor())
            .addPathPatterns("/**")
            .excludePathPatterns("/members/**");
    }
}
  • @EnableWebMvc : WebMvcConfigurationSupport로부터 스프링 MVC 설정을 가져옵니다. 가져온 설정 정보는 @Configuration이 사용합니다.
  1. 애플리케이션을 실행하고 "http://localhost:8080/hello"를 호출하여 로깅이 뜨는지 확인합니다. image

References

Clone this wiki locally