스프링 프레임워크 기초 설명
1
사용자의 Request(요청d)는 Front - Controller인 DispatcherServlet을 통해서 처리한다.
생성된 프로젝트의 web.xml을 보면 아래와 같이
모든 Request를 DispatcherServlet이 받도록 처리하고 있다.
<!-- Processes application requests --> <servlet> <servlet-name>appServlet</servlet-name> <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class> <init-param> <param-name>contextConfigLocation</param-name> <param-value>/WEB-INF/spring/appServlet/servlet-context.xml</param-value> </init-param> <load-on-startup>1</load-on-startup> </servlet> <servlet-mapping> <servlet-name>appServlet</servlet-name> <url-pattern>/</url-pattern> </servlet-mapping>
2, 3
HandlerMapping은 Request의 처리를 담당하는 컨트롤러를 찾기 위해서 존재한다. HandlerMapping 인터페이스를 구현한 여러 객체들 중
RequestMappingHandlerMapping 같은 경우는
개발자가 @RequestMapping 어노테이션이 적용된 것을 기준으로 판단하게 된다.
적절한 컨트롤러가 찾아졌다면 HandlerAdapter를 이용해서 해당 컨트롤러를 동작시킨다.
4
Controller는 개발자가 작성하는 클래스로 실제 Request를 처리하는 로직을 작성하게 된다.
이때 View에 전달해야 하는 데이터는 주로 Model이라는 객체에 담아서 전달한다.
Controller는 다양한 타입의 결과를 반환하는데
이에 대한 처리는 ViewResolver를 이용하게 된다.
5
ViewResolver는 Controller가 반환한 결과를
어떤 View를 통해서 처리하는 것이 좋을지 해석하는 역할이다.
가장 흔하게 사용하는 설정은 servlet-context.xml에 정의된 InternalResourceViewResolver다.
<!-- Resolves views selected for rendering by @Controllers to .jsp resources in the /WEB-INF/views directory --> <beans:bean class="org.springframework.web.servlet.view.InternalResourceViewResolver"> <beans:property name="prefix" value="/WEB-INF/views/" /> <beans:property name="suffix" value=".jsp" /> </beans:bean>
6, 7
View는 실제로 응답 보내야 하는 데이터를 Jsp 등을 이용해서 생성하는 역할을 하게된다.
만들어진 응답은 DispatcherServlet을 통해서 전송된다.
=================================================================
위의 그림을 보면 모든 Request는 DispatcherServlet을 통하도록 설계되는데,
이런 방식을 Front-Controller 패턴이라고 한다.
Front-Controller 패턴을 이용하면 전체 흐름을 강제로 제한할 수 있다.
예를 들어 HttpServlet을 상속해서 만든 클래스를 이용하는 경우
특정 개발자는 이를 활용할 수 있지만
다른 개발자는 자신이 원래 하던 방식대로 HttpServlet을 그대로 상속해서 개발할 수도 있다.
Front-Controller 패턴을 이용하는 경우에는
모든 Request의 처리에 대한 분배가 정해진 방식대로만 동작할기 때문에
좀 더 엄격한 구조를 만들어 낼 수 있다.
spring-beans : 스프링 컨테이너를 이용해서 객체를 생성하는 기본 기능 제공
spring-context : 객체 생성, 라이프 사이클 관리, 스키마 확장 등의 기능 제공
spring-aop : 프락시 기반 AOP 기능 제공
spring-web : REST 클라이언트, 데이터 변환 처리, 서블릿 필터, 파일 업로드 지원 등 웹개발에 필요한 기능 제공
★spring-webmvc : 스프링 기반의 웹 MVC 프레임워크, 웹 애플리케이션 개발하는데 필요한 컨트롤러 구현 제공
spring-websocket : 스프링 MVC에서 웹소켓을 사용하기 위한 기능 지원
spring-oxm : XML과 자바 객체 간 매핑을 처리하기 위한 API 제공
spring-tx : 트랜잭션 처리 위한 추상 레이어 제공
spring-jdbc : JDBC 프로그래밍을 보다 쉽게 할 수 있는 템플릿 제공, 이를 이용하면 JDBC 프로그램에서 반복적으로 입력해야하는 코드 줄일 수 있음
srping-orm : 하이버네이트, JPA, MyBatis 등과 연동 지원
spring-jms : JMS 서버와 메시지를 쉽게 주고 받을 수 있도록 템플릿과 아노테이션 등 제공
sring-context-support : 스케줄링, 메일발송, 캐시연동, 벨로시티 등 부가기능 제공
POJO(Plain Old Java Object) 기반의 프레임워크
- 자바 객체의 라이프사이클을 스프링 컨테이너가 직접 관리하며, 스프링 컨테이너로부터 필요한 객체를 얻어올 수 잇음
★DI(Dependency Injection)을 지원
- 각 계층이나 서비스들 사이 또는 객체들 사이에 의존성이 존재할 경우 스프링 프레임워크가 서로를 연결시켜줌 이는 클래스들 사이에 약한 결합을 가능하게 함(의존성↓)
------ 주입 방법 : 생성자, 멤버, 어노테이션, xml
AOP(Aspect Oriented Programming)를 지원
- 트랜잭션, 로깅, 보안 등 여러 모듈에서 공통적으로 지원하는 기능을 분리하여 사용 가능, 확장성 높음
- 스프링 프레임워크의 소스는 모두 라이브러리로 분리시켜 놓음으로써 필요한 라이브러리만 가져다 쓸 수 있다 그리고 많은 외부 라이브러리들도 이미 스프링 프레임워크와 연동되고 있다
- Model2 방식의 MVC Framework를 지원
전체적인 설계가 만들어지고 거기에 대한 관점을 보는 것 : AOP
maven : 스프링
gradle : 안드로이드 프로젝트
기본적인 웹 게시물 관리
스프링 MVC와 Mybatis를 이용한
CRUD(등록, 수정, 삭제, 조회)와
페이징 처리
검색기능 의 게시물 관리를 제작.
중요하게 고려해야 할 부분
스프링 MVC를 이용하는 웹 프로젝트 전체 구조에 대한 이해
개발의 각 단계
Presentation(화면 계층 ) : 화면에 보여주는 기술을 사용하는 영역
Servlet/JSP나 스프링 MVC가 담당하는 영역.
프로젝트의 성격에 맞추어 앱으로 제작하거나,
CS(Client - Server)로 구성되는 경우도 있다.
스프링 MVC와 JSP를 이용한 화면 구성이 이에 속한다.
Business(비즈니스 계층) : 순수한 비느니스 로직을 담고 있는 영역
이 영역이 중요한 이유
고객기 원하는 요구사항을 반영하는 계층.
이 영역의 설계는 고객의 요구 사항과 정확히 일치해야 한ㄷ.
이 영역은 주로 xxxService와 같은 이름으로 구성하고,
메서드 이름 역시 고객들이 사용하는 용어를 그대로 사용하는 것이 일반적.
Persistence(영속 또는 데이터 계층) : 데이터를 어떤 방식으로 보관하고, 사용하는가에 대한 설계가 들어가는 계층.
일반적인 경우, 데이터베이스를 많이 이용하지만,
경우에 따라서 네트워크 호출이나 원격 호출 등의 기술이 접목될 수도 있다.
이 영역은 Mybatis와 mybatis-spring을 이용하여 구성.
Spring MVC : Presentation Tier를 구성,
root-context.xml, servleet-context.xml 등의 설정 파일이 해당 영역의 설정을 담당
Spring Core : POJO(Plain-Old-Java-Object)의 영역.
스프링의 의존성 주입을 이용해서 객체 간의 연관구조를 완성하여 사용
Mybatis : 현실적으로 mybatis-spring을 이용하여 구성하는 영역.
SQL에 대한 처리를 담당하는 구조
프로젝트를 3-tier로 구성하는 이유는 유지보수에 대한 필요성 때문
각 영역은 독립적으로 설계되어 추후 특정 기술이 변하더라도 필요한 부분을 전자제품의 부품처럼
쉽게 교환할 수 있게 하는 방식
각 영역은 설계 당시부터 영역을 구분하고,
해당 연결 부위는 인터페이스를 이용하여 설계하는 것이 일반적
1. 네이밍 규칙
xxxController :
스프링 MVC에서 동작하는 Controller 클래스를 설계할 때 사용
xxxService, xxxServiceImpl :
비즈니스 영역을 담당하는 인터페이스는 xxxService 방식.
인터페이스를 구현한 클래스는 xxxServiceImpl 이름 사용
xxxDAO, xxxRepository :
DAO(Data-Access-Object)나 Repository(저장소) 이름으로 영역을 따로 구성하는 것이 보편적
별도의 DAO를 구성하는 대신, Mybatis의 Mapper 인터페이스를 활용
VO, DTO :
VO나 DTO는 일반적으로 유사한 의미로 사용하는 용어
데이터를 담고 있는 객체를 의미한다는 공통점이 있다
VO :
주로 Read Only 목적이 강하고, 데이터 자체도 immutable(불변)하게 설계하는 것이 정석
DTO :
주로 데이터 수집의 용도가 좀 더 강하다
예) 웹 화면에서 로그인하는 정보를 DTO로 처리하는 방식을 사용
테이블과 관련된 데이터는 VO라는 이름 사용
패키지의 구성은 프로젝트의 크기나 구성원들의 성향으로 결정
규모가 적은 프로젝트 :
Controlelr 영역을 별도의 패키지로 설계
Service 역역 등을 하나의 패키지로 설계
규모가 큰 프로젝트 :
많은 Service 클래스와 Controller들이 흔재할 경우,
비즈니스를 단위별로 구분하고(즉, 비즈니스 단위별로 패키지 작성)
다시 내부에서 Controller 패키지, Service패키지 등으로 다시 나누는 방식 이용
담당자가 명확해지고, 독립적인 설정을 가지는 형태로 개발[작업 패키지 구성]
com.이니셜 : 메인 패키지
com.이니셜.config : 프로젝트와 관련된 설정 클래스들
com.이니셜.controller : 스프링 MVC의 Controller들
com.이니셜.service : 스프링의 Service 인터페이스와 구현 클래스들
com.이니셜.domain : VO, DTO 클래스들
com.이니셜.persistence : Mybatis Mapper 인터페이스
com.이니셜.exception : 웹 관련 예외처리
com.이니셜.aop : 스프링의 AOP 관련
com.이니셜.security : 스프링의 Security 관련
com.이니셜.util : 각종 유틸리티 클래스 관련프로젝트를 진행하기 전에
고객의 요구사항을 인식하고, 이를 설계하는 과정이 필요
요구사항 분석 설계 :
고객이 원하는 내용이 무엇이고,
어느 정도까지 구현할 것인가에 대한 프로젝트의 범위를 정하는 것이 목적.
요구사항 :
실제로 방대해 질 수 있으므로 프로젝트에서는 단계를 정확히 구분.
경험이 많은 팀 구성 : 초기버전에 상당히 많은 기능을 포함 시켜서 개발
반대의 경우 : 최대한 단순하고 눈에 보이는 결과를 만들어 내는 형태로 진행.
온전한 문장으로 정리.
주어는 "고객"이고, 목적어는 "대상(domain)"이 된다.
예) 게시판의 경우, 게시물이 대상이 된다.
고객은 새로운 게시물을 등록할 수 있어야 한다.
고객은 특정 게시물을 조회할 수 있어야 한다.
고객은 작성한 게시물으 삭제할 수 있어야 한다.
등.
테이블 : tbl_board
VO클래스 : com.이니셜.domain.BoardVO
게시물과 관련된 로직 : com.이니셜.service.BoardService / com.이니셜.BoardController
요구사항에 따른 화면 설계
예) 고객은 새로운 게시물을 등록할 수 있어야 한다.
세부적인 설계 : '어떤 내용들을 입력하게 될 것인가'
이를 기준으로 테이블이나 클래스의 멤버 변수(인스턴스 변수)들을 설계.
이러한 화면을 설계할 때는 주로 Mock-up(목업) 들을 이용하는 경우가 많다.
대표적인 Mock-up툴 : PPT, Balsqmiq studio, Pencil Mockup 등.
각 화면을 설계하는 단계에서는
사용자가 입력해야 하는 값과 함께
전체 페이지의 흐름을 설계.(유즈케이스 다이어그램)
이 화면의 흐름을 URL로 구성하게 되는데,
이 경우 GET/POST 방식에 대하여 언급한다.
3. 게시물 관리 프로젝트 구성
스프링 프로젝트 이름 : springboard
스프링 프로젝트 생성 : Spring Legacy Project
프로젝트 생성 후, 진행 순서:
pom.xml의 수정
데이터 베이스 관련 처리
스프링 MVC 처리
스프링 폴더 설명
스프링 버전 5 사용하기
사용하기 전, pom.xml 버전 통일하기
스프링 관련 라이브러리 추가
spring-tx : 트랜잭션을 사용하기 위한 라이브러리
spring-jdbc : 데이터베이스와 연동하기 위한 라이브러리
spring-test : 테스트 코드를 단위 테스트하기 위한 라이브러리
<!-- Spring Transaction -->
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-tx</artifactId>
<version>${org.springframework-version}</version>
</dependency>
<!-- Spring JDBC -->
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-jdbc</artifactId>
<version>${org.springframework-version}</version>
</dependency>
<!-- Spring Test -->
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-test</artifactId>
<version>${org.springframework-version}</version>
</dependency>
Mybatis 관련 라이브러리 추가
HikariCP : 대용량 데이터 처리 속도를 빠르게 하기 위한 라이브러리
MyBatis : 데이터베이스 프레임워크
mybatis-spring : MyBatis 를 사용하기 위한 스프링 라이브러리
Log4jdbc : 데이터베이스 실행 시, 단위 테스트를 위한 라이브러리
<!-- HikariCP -->
<dependency>
<groupId>com.zaxxer</groupId>
<artifactId>HikariCP</artifactId>
<version>2.7.8</version>
</dependency>
<!-- MyBatis -->
<dependency>
<groupId>org.mybatis</groupId>
<artifactId>mybatis</artifactId>
<version>3.4.6</version>
</dependency>
<!-- mybatis-spring -->
<dependency>
<groupId>org.mybatis</groupId>
<artifactId>mybatis-spring</artifactId>
<version>1.3.2</version>
</dependency>
<!-- Log4jdbc -->
<dependency>
<groupId>org.bgee.log4jdbc-log4j2</groupId>
<artifactId>log4jdbc-log4j2-jdbc4</artifactId>
<version>1.16</version>
</dependency>설치 방법(cmd)
java -jar lombok.jar
만약, x표시가 뜬다면
':: IT > Spring' 카테고리의 다른 글
| AOP (0) | 2020.05.20 |
|---|---|
| [스프링프레임워크] 컨트롤러 작성, DAO,DTO,VO설명, 상세보기 (0) | 2020.05.14 |
| [스프링프레임워크]VO클래스 작성, 수정,삭제 구현 (0) | 2020.05.13 |
| [스프링프레임워크]오라클 테이블 생성과 Dummy 데이터 생성, (0) | 2020.05.12 |