treecode

디자인 패턴은 소프트웨어 설계 시 특정 상황에서 자주 만나는 문제를 해결하기 위해 사용할 수 있는 재사용 가능한 솔루션으로 디자인 패턴에서 중요한 것은 각 패턴의 핵심이 담긴 목적 또는 의도이다.

1. 패턴을 적용할 상황

2. 해결해야 될 문제

3. 핵심 의도가 무엇인지

메서드를 추상 메서드(abstaract method)로 선언해서 자식 클래스가 이를 상속 받아 메서드를 구현하도록 하면 클래스 계층구조를 통해 관심을 분리할 수 있다. (DB의 커넥션 연결 등과 SQL, DB 접근 등의 로직을 분리)

상속을 통해 기능을 확장하는 방법으로 사용되는 2가지 패턴이 있는데 먼저 템플릿 메서드 패턴(template method pattern)은 부모 클래스에서 자주 변경되거나 확장할 기능을 추상 메서드나 오버라이드 가능한 메서드를 정의해둔 템플릿 메서드를 만들어서 자식 클래스에서 해당 메서드를 구현하도록 하는 패턴이다. (훅(Hook) 메서드 : 부모 클래스에서 디폴트 기능을 정의해두거나 비워뒀다가 자식 클래스에서 오버라이드할 수 있도록 만들어둔 메서드)

팩토리 메서드 패턴(factory method pattern)은 자식 클래스에서 객체 생성 방법과 클래스를 결정할 수 있도록 미리 정의해둔 메서드(팩토리 메소드)를 통해 객체의 생성을 부모 클래스의 기본 코드에서 독립시키는 패턴이다.

관심을 분리한다는 것은 내부 동작에 상관없이 관심을 두지 않고 필요한 기능만 가져다 사용한다는 것이다. 

템플릿 메서드 패턴, 팩토리 메서드 패턴을 사용하면 관심 사항이 다른 코드를 분리해내고, 서로 독립적으로 변경, 확장을 할 수 있다. 하지만 상속을 사용하기 때문에 클래스의 다중 상속이 허용되지 않는 자바에서는 비용이 큰 편이고, 결합력이 높기 때문에 관심 사항은 분리했더라도 변경 시 변화의 파급력이 큰 편이다. 그래서 토비의 스프링 책에서는 인터페이스를 사용하여 분리를 하는 방식을 권장하는데 인터페이스를 사용하면 다형성으로 인해 의존관계를 외부에서 주입하고 클래스에서는 인터페이스 타입의 참조 변수를 통해 구현체의 메서드를 사용하면 되기 때문에 완벽하게 분리를 할 수 있다. 구현체가 변경이 되더라도 외부에서 변경된 구현체로 주입을 해주면 된다.

이렇게 보면 인터페이스를 사용하면 될 것 같은데 템플릿 메서드 패턴을 왜 쓰는지, 어떤 상황에 쓰이는지 잘 모르겠다. 다른 블로그를 찾아보다보니 템플릿 메서드 패턴과 비슷하면서 상속의 단점을 제거할 수 있는 전략 패턴이 있다고 하는데 인프런 김영한님의 스프링 고급편에도 템플릿 메서드 패턴에 대한 목차가 있어서 강의를 통해 더 깊게 공부해보고 코드로 사용해보면서 정리를 해봐야겠다.

[참고]

토비의 스프링

Swagger란 REST API를 문서화하여 보기 편하게 시각화하고, 테스트할 수 있는 라이브러리로 서버 가동시 @RestController를 읽어서 API 분석을 해서 HTML로 문서화를 하기 때문에 API 문서를 직접 만들어서 수정시마다 일일이 수정하는 번거로움이 없어진다.

1. build.gradle

springfox-boot-starter로 추가하면 필요한 하위 라이브러리들이 전부 추가된다.

2. application.properties

spring boot 2.6.0 버전 이상인 경우에는 application.properties에서 spring.mvc.pathmatch.matching-strategy=ant_path_matcher을 추가하거나 2.6.0 밑으로 버전을 낮춰야 한다.

3. SecurityConfig

스프링 시큐리티를 사용하는 경우 해당 경로가 필터에 걸리지 않도록 permit해준다.

4. SwaggerConfig

Swagger 3.0을 사용하는 경우 Swagger2.x에서 사용하던 @EnableSwagger2 애노테이션을 사용하면 안 되고 Docket 생성시 DocumentationType.OAS_30으로 설정을 해야한다.

Swagger UI 화면을 보면 Contact와 ApiInfo에 입력한 정보들이 어디에 입력이 되는지 비교가 될 것이다.

그리고 JWT를 사용하기 때문에 관련 설정들을 해줘야 하는데 securitySchems는 API를 보호하는데 사용되는 보안 체계를 설정하는 것으로 ApiKey(또는 BasicAuth, OAuth)를 등록해서 JWT가 Authorization Header에 포함되도록 한다.

securityContext는 ApiKey로 정의한 JWT의 authorizationScope를 설정해서 SecurityReference를 포함해서 생성을 한다.

이제 실행을 하고 http://localhost:8080/swagger-ui/index.html 로 접속을 하면 아래와 같은 메인 화면이 뜬다. 

Authorize를 누르면 ApiKey로 등록한 정보가 나온다.

면접에서 리다이렉트(Redirect)와 포워드(Forward)의 차이점을 물어보는 질문이 나왔는데 포워드가 정확히 기억이 안 나서 대답을 못 했다.

먼저 리다이렉트는 웹 브라우저에게 해당 url로 다시 요청을 하라고 응답을 보낸다. 그래서 새로운 요청이 보내지기 때문에 url도 바뀌게 된다. 리다이렉트는 주로 POST 요청에서 사용을 하는데 HTTP 메서드중 POST는 예외적으로 멱등성이(똑같은 요청에 대해 같은 결과가 나오는 것) 성립하지 않기 때문에 새로고침 같은 반복 요청이 올 경우 리소스 생성이 여러번 일어나면서 문제가 생길 수 있다. 그래서 일반적으로 PRG(Post -> Redirect -> Get) 패턴으로 리다이렉트를 해준다.

리다이렉트를 할 때 redirectAttributes에 addAttribute() addFlashAttribute()를 사용하는 이유는 addAttribute의 경우에는 GET 요청 시 쿼리파라미터로 생성된 게시글의 id값을 넘겨주기 위함이고, addFlashAttribute()는 쿼리 파라미터로 넘겨지지 않고 일회성 용도로 사용이 된다. (저장이 완료되었다는 알림창을 띄우는 등)

redirect:/ 를 사용하면 UrlBasedViewResolver가 viewName이 "redirect"로 시작하는 것을 인식하고 동작을 한다.

타임리프의 th:if 문법으로 result의 값이 true일 경우 리다이렉트로 넘어온 것을 확인해서 저장이 완료되었다고 출력하게 하였다.

그리고 redirect 과정이 어떻게 되는지 보려고 디버깅을 해보았는데 블로그분처럼 따라가는게 어려워서 나중에 다시 해봐야겠다. 

(invokeForRequest 반환으로 returnValue에 "redirect:/board/read"가 넘어오는 것까지 확인)

중요한 것은 리다이렉트와 포워드의 차이점인데 리다이렉트는 302 상태코드로 응답을 하고 Location으로 새로운 GET 요청을 한다.

아래와 같이 응답 리다이렉트를 받고 다시 요청이 오게 된다.

반면 포워드는 온전히 서버측에서 발생하는데 웹 브라우저로 이동하여 새로운 요청이 생기는 것이 아니라 서블릿 컨테이너에서 동일한 요청을 해당 Url로 다시 보내는 것이기 때문에 url은 브라우저에서 바뀌지 않고 처음 요청한 url로 보이게 된다. (Request 객체가 살아있는 것)

사실 리다이렉트만 필요시 사용을 해보고 포워드를 활용해서 다른 url로 넘겨서 사용해본 적이 없어서 어떤 상황에 쓰이는지 잘 모르겠다.

스프링에서 Mybatis를 사용하기 위해서는 Mybatis 스프링 연동 모듈이 필요한데 이는 마이바티스와 스프링을 편하고 간단하게 사용할 수 있도록 지원해준다.

SqlSessionFactory

데이터 베이스의 연결과 SQL 실행에 대한 모든 것을 가지고 있으며 DataSource를 필요로 한다.

@Configuration
public class MyBatisConfig {
  @Bean
  public SqlSessionFactory sqlSessionFactory() throws Exception {
    SqlSessionFactoryBean factoryBean = new SqlSessionFactoryBean();
    factoryBean.setDataSource(dataSource());
    return factoryBean.getObject();
  }
}

스프링은 SqlSessionFactoryBean에서 getObject() 메서드를 호출하여 반환된 SqlSessionFactory를 빌드하여 sqlSessionFactory 라는 이름으로 저장한다. SqlSessionFactoryBean이나 SqlSessionFactory를 직접 사용할 일은 없고 MapperFactoryBean를 확장하는 다른 DAO에 주입 될 것이다.

MapperFactoryBean

MapperFactoryBean은 SqlSession을 생성하고 닫는 역할을 하며 실행중인 스프링 트랜잭션을 관리하고 예외 발생시 스프링의 DataAccessException예외로 변환해준다. 

@Configuration
public class MyBatisConfig {
  @Bean
  public UserMapper userMapper() throws Exception {
    SqlSessionTemplate sqlSessionTemplate = new SqlSessionTemplate(sqlSessionFactory());
    return sqlSessionTemplate.getMapper(UserMapper.class);
  }
}

SqlSesssion과 SqlSessionTemplate

SqlSession은 SqlSessionFactory에 의해 생성되며 매핑 구문을 실행하거나 트랜잭션 커밋, 롤백 등을 할 수 있는데 마이바티스 스프링 연동 모듈은 자동으로 SqlSession을 스프링 빈에 주입하고 스프링이 직접 트랜잭션을 관리한다. 

스프링이 관리하는 SqlSession에서는 SqlSession.commit(), SqlSession.rollback() 또는 SqlSession.close() 메서드를 호출할수가 없다. (사용 시 UnsupportedOperationException 예외가 발생)

SqlSessionTemplate은 인자로 SqlSessionFactory를 받아서 생성되는데 SqlSession이 현재의 스프링 트랜잭션에서 사용 될 수 있도록 보장하는데 필요한 시점에 세션을 닫고, 커밋하거나 롤백하는 것을 포함한 세션의 생명주기를 관리한다. 또한 마이바티스 예외를 스프링의 DataAccessException로 변환하는 작업도 처리한다.

TransactionManager

마이바티스 스프링 연동 모듈은 스프링 PlatformTransactionManager의 구현체인 DataSourceTransactionManager를 사용하여 스프링 트랜잭션에 자연스럽게 연동될 수 있는데 DataSourceTransactionManager는 Connection 객체에 존재하는 트랜잭션 API를 사용하여 트랜잭션을 관리해주는 TransactionManager다.

참고)

JPA는 JpaTransactionManager를 사용하며 EntityManagerFactory가 스프링 빈으로 등록된 DataSource를 사용하는데 JPA에서 사용하는 DataSource를 Mybatis에서도 사용할 수 있다. Mybatis만 사용할 경우 DataSourceTransactionManager를 스프링 빈으로 등록하지만, JPA를 사용할 경우 JPATransactionManager로 같이 관리가 가능하기 때문에 별도의 TransactionManager를 등록할 필요가 없다.

Mapper Interface

Mybatis XML 파일에 SQL을 호출하기 위한 인터페이스로  편리하게 XML의 데이터를 찾아서 호출해주고 MyBatis에서 발생한 예외를 스프링 예외 추상화인 DataAccessException에 맞게 변환해주는 등 지금까지 말한 기능들을 담당한다.

Mybatis 3.0 이후 버전부터는 SqlSessionTemplate를 직접적으로 사용하는 DAO를 생성하지 않고 다른 빈에 직접 주입할 수 있는 쓰레드에 안전한 매퍼를 생성하여 사용한다. 리포지토리에 Mapper 인터페이스를 주입하여 사용하는 것을 생각하면 된다. 여러 설정들이 간편하게 자동화되며 스프링 부트를 사용하면 Mapper 인터페이스를 Bean으로 등록할 필요도 없이 @Mapper 애노테이션만 사용하면 된다.

Mybatis-Spring-Boot-Starter

• DataSource 자동 감지
• SqlSessionFactoryBean을 사용해서 DataSource를 전달하는 SqlSessionFactory의 객체를 생성하고 등록
• SqlSessionFactory를 이용해 SqlSessionTemplate를 생성하고 등록
• Mapper를 스캔한 뒤 SqlSessionTemplate에 연결하고 Mapper 인터페이스를 프록시 구현체로 생성하여 스프링 빈으로 등록해서 리포지토리에 주입할 수 있게 해준다.