[3] 간략한 스프링 개요 - PSA

1. PSA

PSA란 Portable Service Abstraction 이라고 합니다

 

자바 스프링은 서블릿 어플리케이션을 만듦에도 불구하고

서브릿을 직접 프로그래밍하지 않습니다. 

 

일반적으로 하나의 엔드포인트에 여러 메소드를 대응시키기 위해

java에 구현된 HttpServlet 을 상속받아

해당 HttpServlet의 doGet, doPost 메소드를 오버라이딩하여 비즈니스 로직을 작성하게 됩니다. 

 

public class OwnerCreateServlet extends HttpServlet {

	@Override
	protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {
		super.doGet(req, resp);
	}

	@Override
	protected void doPost(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {
		super.doPost(req, resp);
	}
}

위와 같은 식으로 말이죠. 

이와 같은 서블릿을 WEB.xml에 특정 엔드포인트와 매핑하여 구성합니다.

그럼 그 서블릿은 하나의 엔드포인트의 여러 메소드의 요청을 담당하게 됩니다. 

 

그런데 스프링에선 그런식으로 코딩을 하지 않고

GetMapping, PostMapping 등의 어노테이션을 이용합니다. 

URL도 매우 편하게 변경할 수 있지요

 

이게 끝이라고? 너무 편하다

 

이렇게 만 써도 서블릿 기반으로 코드가 동작하기 때문에

더욱 편하게 프로그래밍할 수 있습니다. 

 

Service Abstraction 을 제공하는 것엔 목적과 디자인 철학이 담겨있는데요

간단하게 이야기하면, 내부 구현이 달라져도 동일한 인터페이스로 동일한 구동이 가능하게끔 설계하여

어떤 구현을 채택하든 기능이 훼손되지 않게끔 하는 것입니다. 

 

M -> Model

V -> View

C -> Controller

 

Spring에서는 Spring Web MVC 와 관련된 서비스 추상화가 대표적입니다. 

@Controller 라는 어노테이션을 이용하면 요청을 매핑할 수 있는 객체가 됩니다.

해당 클래스 내의 메소드에 @GetMapping 등의 어노테이션으로 url에 해당하는 메소드의 요청을 매핑합니다. 

 

이러한 구조를 유지하고, 뒷단의 서버를 톰캣에서 제티, 네티, 언더토우로 변경하던

서블릿 방식을 Reactive 방식으로 변경하던 상관없이

기존 코드의 흐름을 그대로 유지할 수 있는 것이 큰 장점입니다.

 

2. Spring Transaction

 

JDBC 에서 트랜잭션 Autocommit -> false 후 commit 하는 방식으로 처리했다면

Spring에선 @Transactional 어노테이션만 붙이면 트랜잭션화 되기 때문에 

굳이 예외처리를 직접 하지 않아도 됩니다. 

 

이게 PSA의 예시인 이유는 Datasource, Hibernate 등 구현체에 구애받지 않고

사용할 수 있기 때문입니다. 기술이 변경되어도 코드를 변경하지 않아도 됩니다.