스프링과 스프링 MVC

스프링이란?

스프링은 표준 및 엔터프라이즈 자바 으용 프로그램을 신속하게 개발하는 데 널리 사용되는 오픈소스 프레임워크이다.

보통 '스프링'이라고 하지만, 정확한 표현은 '스프링 프레임워크'이다.

 

스프링을 채택하는 이유

스프링을 채택하는 이유는 JAVA EE 플랫폼에서 웹 애플리케이션을 신속하게 개발할 수 있고 모든 인프라 요구 사항을 제공하는 경량급 오픈 소스 프레임워크이며 규모가 큰 애플리케이션을 개발할 때 복잡함을 제거하여 훨씬 빠르고 간편하게 개발하고 효율적으로 구현할 수 있어 생산성과 품질 면에서도 우수하다. 또한 개발이 완료된 후 사후 관리를 위한 유지 보수도 손쉽게 할 수 있다. 이처럼 스프링은 사용성과 확장성뿐만 아니라 대규모 서버로서 성능도 뛰어나기 때문에 이미 다양한 환경에서 검증되어 대세로 자리 잡았다.

 

스프링을 배우는 이유

자바는 웹 애플리케이션을 개발할 때 한 클래스 안에서 수직적인 흐름만 제어할 수 있다. 반면 스프링은 특정 클래스에 대한 수평적 처리까지 가능하기에 더욱 강력하다. 스프링은 의존성 주입(Dependency Injection, DI)이나 관점 지향 프로그래밍(Aspect Oriented Programming, AOP)과 같은 기능뿐만 아니라 기본적으로 웹을 개발할 수 있는 웹 MVC 프레임워크도 함께 제공한다.

 

일반적인 자바 객체를 위한 POJO 지원

스프링은 별도의 API(Application Programming Interface)를 이용하여 애플리케이션 코드를 따로 작성하지 않는 정책을 쓰고 있다. 또한 스프링에서는 자바 서블릿 코드를 작성할 때처럼 인터페이스를 반드시 구현해야 한다거나 HttpServlet 클래스를 상속하지 않아도 된다. 다시 말해 스프링은 일반적인 자바 언어와 꼭 필요한 API 외에는 특정 구현 기술에 종속되지 않으며, 특정 데이터베이스나 서버에 의존하지 않는 자바 클래스만으로 구성해도 프로그래밍이 가능하다. 이런 개념을 POJO(Plain Old Java Object)라고 한다.

 

비즈니스 로직이란?

비즈니스 로직(Business Logic)이란 업무에 필요한 데이터를 처리하는 애플리케이션의 일부를 의미한다.

 

객체 간 결합도를 줄이는 의존성 주입 지원

의존성 주입이란 객체 간 관계를 관리할 때 사용하는 기법이다. 객체 또는 구성 요소 사이의 의존 관계를 직접 생성하거나 제어하는 것이 아니라 외부의 빈(Bean) 설정 파일을 활용하여 스프링 컨테이너가 자동으로 연결하는 방식이다.

 

개발자는 객체 의존 관계가 필요할 때만 외부의 빈 설정 파일(*.xml)에 관련 정보를 추가해 주면 된다.

 

의존성 주입의 주요 장점은 두 객체 간 의존 관계를 줄이는 느슨한 결합도(Loose Coupling)이다. 객체 간 의존 관계를 유연하게 처리하려면 인터페이스를 활용해야 한다. 인터페이스를 활용하면 의존 객체를 바꾸지 않고 인터페이스를 구현한 클래스로 변경하여 사용할 수 있다.

 

느슨한 결합도란?

두 객체 간 의존 관계를 줄이는 것(느슨하게 만드는 것)이다.

 

공통 모듈을 재사용하는 AOP 지원

각 모듈은 대체로 자신의 핵심 기능 외에도 로깅이나 트랜잭션 관리, 보안 등 시스템 서비스를 수행해야 하는 경우가 많다. 이런 시스템 서비스는 시스템의 여러 컴포넌트와 관련되므로 이를 공통 관심사(Cross-Cutting Concerns)라고 한다.

 

애플리케이션 내부에서 공통 관심사를 비즈니스 로직으로 분리하고, 이 공통 관심사를 효과적으로 애플리케이션에 삽입하는 기술이 관점 지향 프로그래밍이다. 즉, 핵심적인 기능에서 부가적인 공통 관심사를 분리하여  애스팩트(Aspect)라는 독특한 공통 모튤을 만들어 설계하고 개발하는 방법이다.

 

의존성 주입이 애플리케이션의 객체 간 결합도를 낮춘다면, AOP는 애플리케이션 전체에 걸쳐 사용되는 기능을 애스팩트에 담아 재사용할 수 있게 한다. 

 

공통 모듈을 각 독립된 모듈로 중복 없이 작성하고, 이를 적합한 위치인 XML 설정 파일에 설정해서 핵심 관점 코드와 결합하여 서로 독립된 다차원의 모듈로 만들 수 있다.

 

트랜잭션이란?

쪼갤 수 없는 최소 단위의 작업이다. 애플리케이션을 개발할 때 데이터 무결성과 일관성을 보장하는 필수 기법이다. 즉, 어떤 작업 프로세스를 하나로 묶어 실행하다 작업이 하나라도 실패하면 모두 실패 처리하고, 전체 작업이 성공하면 성공으로 처리하는 논리적인 작업 묶음이다.

 

일관성 있는 모듈의 트랜잭션 지원

스프링은 데이터베이스 연동 기술과 트랜잭션 서비스 사이의 종속성을 제거하고 트랜잭션을 처리하는 일관된 방법을 제공한다. 즉, 스프링이 제공하는 트랜잭션 추상 계층을 이용하면 데이터베이스 연동 기술과 상관없이 같은 방식으로 트랜잭션 기능을 활용할 수 있다. 또한 트랜잭션 서비스의 종류나 환경이 바뀌더라도 트랜잭션을 사용하는 코드는 그대로 유지하는 유연성도 제공한다.

트랜잭션 관리 방법은 크게 프로그래밍적 트랜잭션과 선언적 트랜잭션으로 구분할 수 있는데, 스프링은 이 두 가지를 모두 지원한다. 프로그래밍적 트랜잭션(Programmatic Transaction) 처리는 코드에서 트랜잭션 범위를 정교하게 정의할 수 있지만, 트랜잭션이 스프링의 종속적인 코드가 될 가능성이 크다. 선언적 트랜잭션 처리(Declarative Transaction)는 코드를 수정하지 않고도 트랜잭션을 적용하거나 변경할 수 있다. 또한 간편하게 XML 설정 팡일이나 애너테이션을 이요하여 트랜잭션의 범위와 규칙을 정의할 수 있으므로 트랜잭션을 매우 쉽게 관리할 수 있다.

 

스프링 MVC

스프링 MVC는 스프링이 제공하는 웹 애플리케이션 개발 전용 프레임워크로, MVC(모델(Model)-뷰(View)-컨트롤러(Controller) 패턴을 사용한다.

 

모델(Model) : 애플리케이션의 데이터가 들어 있는 객체이다.

뷰(View) : 모델의 정보(데이터)를 특정 형식으로 나타낸다. 일반적으로 JSP와 JSTL은 뷰 페이지를 작성하는 데 사용된다.

컨트롤러(Controller) : 애플리케이션의 비즈니스 로직을 포함한다. 여기에서 @Controller 애너테이션은 자바 클래스를 컨트롤러로

                                      표시하는 데 사용된다.

프런트 컨트롤러(Front Controller) : 애플리케이션의 흐름을 관리한다. 스프링 MVC에서 DispatcherServlet 클래스가

                                                           프런트 컨트롤러로 작동한다.

 

스프링 MVC의 구성 요소

스프링 MVC는 웹 브라우저에서 서버로 들어오는 모든 웹 요청을 받아 처리하고, 결과를 되돌려주기까지 디스패처 서블릿(DispatcherServlet)의 도움을 받는다. 디스패처 스블릿은 웹 애플리케이션으로 들어오는 모든 요청을 제어하고 모델-뷰-컨트롤러를 조합하여 웹 브라우저에 출력하는 클래스이다.

구성 요소	설명
디스패처 서블릿(DispatcherServlet)	웹에서 요청을 전달받는다. 전달받은 요청을 컨트롤러에 전달하고, 컨트롤러가 반환한 결과 값을 뷰에 전달하여 알맞은 응답을 생성한다.
핸들러 매핑(HandlerMapping)	클라이언트가 요청한 URL을 어떤 컨트롤러가 처리할지 결정한다.
컨트롤러(Controller)	클라이언트의 요청을 처리한 후 결과를 반환한다. 응답 결과에서 보여 줄 데이터를 모델에 담아 전달한다.
모델 앤 뷰(ModelAndView)	컨트롤러가 처리한 결과 정보와 뷰 선택에 필요한 정보를 담는다.
뷰 리졸버(ViewResolver)	컨트롤러의 처리 결과를 보여 줄 뷰를 결정한다.
뷰(View)	컨트롤러의 처리 결과 화면을 생성한다. 주로 JSP 파일로 클라이언트에 응답 결과를 전송 한다.

 

스프링 MVC의 흐름도

1. 웹 브라우저(클라이언트)에서 URL을 요청하면 가장 먼저 디스패처 서블릿에 절달한다.

2. URL 요청을 받은 디스패처 서블릿은 어느 컨트롤러에서 요청을 처리할지 결정하료고 핸들러 매핑으로 적합한 컨트롤러를 검색한다.

3. 핸들러 매핑은 클라이언트 요청을 처리할 컨트롤러를 결정하여 디스패처 서블릿에 반환한다.

4. 컨트롤러는 해당 클라이언트 요청을 전달받는다. GET 또는 POST 방식을 기반으로 적합한 메서드를 호출한다.

5. 호출된 메서드는 정의된 비즈니스 로직으로 모델 데이터를 설정하고 뷰 이름을 디스패처 서블릿에 반환한다.

6. 디스패처 서블릿은 웹 브라우저에서 들어온 요청을 처리한 결과를 보여 주려고 뷰 리졸버에 도움을 요청하여 응답 결과를 생성할 뷰

    객체를 검색한다.

7. 뷰 리졸버는 적절한 뷰를 결정하여 디스패처 서블릿에 뷰를 반환한다.

8. 디스패처 서블릿은 데이터가 담긴 모델을 뷰로 보내면 클라이언트 요청에 대한 응답 작업을 완료한다.

9. 뷰는 클라이언트 요청에 대한 응답 작업이 완료하여 처리 결과를 디스패처 서블릿에 반환한다.