스프링으로 웹개발 기초

초창기 자바 웹개발에서는 jsp도 없었고 서블릿 클래스만 있었다. 클래스로 개발자가 직접 웹브라우저 요청을 받아 처리하고 리턴할 스트림을 만들어야 했다. jsp가 나왔지만 이 역시 내부적으로는 서블릿클래스로 컴파일되어 서비스되는 것이다. 모델2라는 아키텍쳐가 나오면서 모델과 서비스를 분리하고 개발하기 시작했다. 프레임웍이라는 개념이 도입되면서 여러 프레임웍이 경쟁하다 살아남은게 스프링이다.

 

스프링 기반 MVC아키텍쳐로 개발자가 직접 서블릿코드를 만들어내지 않고 콘트롤러와 서비스와 뷰에 집중하여 개발하면 , 스프링이 설정을 통해 조합해서 특정 경로로 요청하면 해당 콘트롤러가 실행되면서 서블릿으로 서비스를 하게 된다.

 

스프링에서 지원하는 자동화 설정에 따라 DB정보, SQL매핑쿼리, 공통설정을 해 놓고 @어노테이션에 맞춰 컨트롤러 클래스만들고 서비스클래스, DAO클래스 만들고 SQL 매퍼 설정해놓으면 필요한 시점에 스프링이 알아서 조합해서 변신로봇 서블릿으로 웹서비스를 하게 만드는 것이다. 프레임웍이란 개발자에게 코드의 규칙을 강제하는 것으로 우리가 굳이 프레임웍을 만들겠다는 각오로 이해하려 할 필요가 없다.  어디에 어떻게 무엇을 구현해야 하는가만 신경쓰고 개발하면 된다.

 

굳이 프레임웍을 만들거나 그 수준의 코드를 구현하겠다면 개발자보단 SW아키텍트영역의 역할이라고 생각한다.

 

기본적으로 스프링기반 웹APP은 web.xml설정을 찾아서 스프링이 읽어서 로딩하는 context*.xml을 찾아보면 변신과정에 사용하는 빈정보와 설정들이 있다. 거기에 맞춰 수정하고 우리는 스프링 MVC모델에서 제시하는 각각의 클래스와 인터페이스, 매소드를 열심히 만들면서 스프링기반으로 개발하면 된다. 프레임웍은 코드의 주도권을 개발자가 가지는 것이 아니라 프레임웍이 컨트롤한다. 개발자는 프레임웍에 순응하여 열심히 각각의 부속품을 빨리 개발하면 된다.

 

 

 

스프링 프레임워크는 또한 제어의 역전(IoC) 설계 패턴을 따르는데, 이는 응용 프로그램에서 개체 간의 느슨한 결합을 사용한다. 

개발자는 직접 사용자브라우저와 통신하는 서블릿소스를 작성하지 않는다. 그런데 스프링은 컨테이너역할을 수행하여 적절한 시점에 개발자가 만든 클래스를 서블릿으로 변신을 시켜 사용자 브라우저와 소통하게 만든다.

 

DI란 Dependency Injection(의존성 주입)이다.

스프링 프레임워크의 가장 중요한 특징은 객체의 생성과 의존관계를 스프링 IOC(Inversion of Control) 컨테이너가 자동으로 관리 한다.  

개발자가 직접 new문을 사용하여 인스턴스를 생성하는 방식으로 코드를 구현하지 않고, 인터페이스를 통해 느슨한 코드를 구현하고 클래스간의 의존관계를 @ 어노테이션으로 정의하거나 xml설정등을 통해 정의하면 해당 지점에 필요한 객체의 인스턴스를 외부에서 생성시켜 스프링 컨테이너가 자동으로 주입한다 (객체 참조).

 

DI : Dependency Injection(의존성 주입)

– xml 빈설정을 사용한 주입

 

다음은 의존성 주입이 설정된 web.xml파일이다.

 

루트콘텍스트인 contextConfigLocation의 위치와 서블릿 콘텍스트(디스패처)의 위치를 지정한다.

WAS(자바 웹어플리케이션 서버)가 구동되면 해당 위치의 xml파일을 읽어서 의존성 주입이 시작된다.

 

web.xml

servlet-mapping을 살펴보면 action의 url-patten이 *.do 인 요청은 모두 DispatcherServlet에 맡기게 되어 있다.

 

개발자가 직접 서블릿코드를 작성하지 않는다. 개발자는 MVC모델로 각 모델영역에 맞는 코드를 작성하면  DispatcherServlet이 서블릿클래스를 생성해서 사용자 요청을 처리하고 결과를 VIEW에 담아 전달하게 된다.

 

context-datasource.xml

context-datasource.xml에 id="dataSouce"라는 자바 빈을 설정해놓고

 

context-sqlMap.xml

context-sqlMap.xml에서 ref="dataSource"로 참조한 뒤 id="sqlMapClient" 이라는 자바빈을 생성

 

DispatcherServlet

DispatcherServlet은 스프링 웹프레임웍의 핵심으로 클라이언트의 요청을 받아서 설정된 객체들을 조립해서 서블릿으로 사용자요청을 처리하도록 동작한다.

 

DispatcherServlet의 뷰리졸버에 jsp이름을 던져주면 뷰리졸버가 뷰오브젝트를 생성하여 DispatcherServlet전달하면 최종 결과를 클라이언트에게 전달하는 구조이다.

 

의존성 주입과 관련되어 웹개발에 사용되는 어노테이션(@)

어노테이션	설 명	사 용
@Component	스프링이 관리하는 모든 컴포넌트에 관한 기본 스테레오 타입, 비권장	클래스
@Controller	스프링 MVC의 컨트롤러 객체임을 명시	클래스
@RequestMapping	특정 URI에 매칭되는 클래스나 메소드임을 명시	클래스, 메소드
@RequestParam	요청(request)에서 특정한 파라미터의 값을 찾아낼 때 사용	파라미터
@RequestHeader	요청(request)에서 특정 HTTP 헤더 정보를 추출할 때 사용	파라미터
@PathVariable	현재의 URI에서 원하는 정보를 추출할 때 사용	파라미터
@ModelAttribute	자동으로 해당 객체를 뷰까지 전달하도록 만드는 어노테이션	메소드, 파라미터
@SessionAttribute	세션상에서 모델의 정보를 유지하고 싶은 경우에 사용	클래스
@ResponseBody	리턴 타입이 HTTP의 응답 메세지로 전송	메소드, 리턴타입
@RequestBody	요청(request) 문자열이 그대로 파라미터로 전달	파라미터
@RestController	@Controller와 @ResponseBody를 합친 기능	클래스
@Resource	어플리케이션이 필요한 자원을 연결	클래스
@Service	서비스 객체	클래스
@Autowired	DI컨테이너는 관리하고 있는 객체중에서 @Autowired 어노테이션이 붙은 필은 필드에 맞는 객체를 자동으로 찾아내어 주입한다. 이 과정을 오토와이어링이라 함.	클래스, 메소드

 

MVC모델

Model(데이터베이스 or 데이터를 사상한 변수구조체) 

View(입출력인터페이스) 

Controller(모델과 뷰의 가교역할)

 

Controller

@Resource 어노테이션은 서비스객체는 주입에 사용한다. sampleSevervice는 콘트롤러에서 데이터처리를 위한 목적으로 사용되는 서비스객체이다.

 

@RequestMapping 어노테이션은 웹브라우저의 요청을 받아 요청을 처리하기 위해 사용된다. "/egoveSamlimit.do"요청이 웹에서 들어오면 해당 메서도가 실행된다.

 

@ModelAttribute 어노테이션은 브라우저요청 파라미터 정보를 자동으로 전달한다. searchVO는 게시물 목록을 담는 VO(View Object)이다.

 

model.addAttribute("resultList", sampleList)에서 model은 jsp페이지에 넘겨 주기위한 객체이다.

 

addAttribute메서드를 사용해서 "resultList"라는 키로  sampleList 어레이리스트 객체를 집어넣어 주었다.

 

return "sample/egoveSampleList"를 결과를 뷰리졸버에 정의되어 있는 경로 아래 egov밑에 egoveSampleList.jsp 뷰오브젝트로 데이터를 전달한다. 뷰리졸버는 뷰오브젝트를 호출하여 그 결과를  DispatcherServlet에 전달해준다.

 

보는 것 처럼  개발자는 직접적으로 서블릿 코드를 생성하지 않는다. 그리고 객체의 생성도 new문을 사용하지 않고 @어노테이션으로 주입받아서 생성된 오브젝트를 사용한다.

 

Service

스프링은 서비스객체를 생성할 때 인터페이스를 만들고 이 인터페이스를 구현한 실제 서비스 객체형태를 사용한다. 인터페이스를 사용하는 형태를 통해 의존성주입을 용이하게 한다고 하는데 사실 귀찮을 뿐이다.

 

익숙해지면 별로 어렵지않고 편하고 단순하다. 쿼리만 잘 짜면 형태가 반복된다. 서비스객체에 비지니스를 구현해야 하는 경우가 좀 있을 뿐이다.

 

공공기관의 전자정부프레임웍 기반에서는 sqlMapper를 사용하는 DAO를 주로 사용한다.

 

sqlMapper의 장점은 복잡한 쿼리를 구현할 수 있으나 객체지향모델로서 받아 들이기 어려운 부분이 있다. 그러나 사실 작업이 편하면 최고라 생각한다.

 

 

DAO - Data Access Object

DAO는 sqlMapper클래스를 사용하기 위한 wrapper 객체이다.이것도 기본적으로 인터페이스를 만들고 실체 클래스를 만들도록 요구한다.Mapper 인터페이스※ 인터페이스는 클래스가 아니다. 그러므로 상속의 개념은 없다.

 

Mapper  클래스

@Repository 어노테이션은 sqlMapper DAO에 주로 사용되며 DAO의 unchecked오류를 스프링의 DB오류로 바꿔주는 역할을 수행한다.

 

@Repository에 지정된 매퍼클래스는 지정된 이름(여기서는 sampleDAO)으로 @Resource클래스에 의해 인스턴싱된다.(String) insert("sampleDAO.insertSample", vo); 문장의 의미는 마이바티스xml의 "sampleDAO.insertSample"에 매핑되어 동적매서드를 생성한다는 뜻이다.

 

스프링이 기동할 때 sql-map-config.xml을 읽어드리도록 context-*.xml등에 설정이 되어 있다.이 xml에는 로딩할 쿼리를 담은 xml정보가 들어있다.

이 xml은 실행할 쿼리를 관리하는 파일로 종류에 따라 insert, update, select, delete 구문이 있다.

동적 매크로를 사용할 수 있으며 파라미터는 #파리미터# 형태로 받는다.

<![CDATA[  ~~ ]]>감싸는 것은 `>` , `< `같이 특수문자로 인한 문장의 분절을 방지하기 위한 것이다.각 쿼리는  id로 식별되며 DAO 클래스와 함께 인스턴싱된다.

 

View -  jsp뷰리졸버일 경우

기본적으로 jsp에서는 JSTL표현식을 사용하여 컨트롤러에서 받은 모델 rusultList, result 등을 사용하여 파싱하여 구현한다.

 

최근에는 백엔드 랜더링 형태의 서비스보다 프로트앤드 랜더링 기반으로 구현되어 rest API방식으로 데이터를 주고 받아 구형 Legacy사이트에서나 사용된다.

 

공공기관 및 은행등 백앤드기반의 웹개발은 jstl과  html 및 js가 섞이면서 페이지 소스가 어수선해진다. 반면 리액트는 페이지랜더링의 주도권은 js에서 핸들링하게 되어 구조화된 통제가 가능하지만 프론트앤드 기능 복잡도가 3배이상으로 복잡해져 구현 및 유지보수 비용도 3배가 되는 것 같다.

 

예전 백앤드기반 개발자 1명이 할 일을 백앤드 0.5명 및 프로트앤드 3명이 하게 된다. 어느 순간 사이트구조가 미니멀해지고 변곡점이 찾아올 것 같다. 개인적으로 웹페이지 모듈을 너무 파편화하는 것은 바람직하게 보지 않는다.

 

스프링은 이 포스팅 내용으로 정리가 된 것 같다. 실제적으로 게시판이나 쇼핑몰을 만들어보면서 익숙해지면 된다고 생각한다.

 

차후에 스프링 게시판이랑 쇼핑몰정도를 미니프로젝트로 공유하려고 한다.