Java 스프링

Angelo·2020년 11월 7일

[Java]독학

SPRING

목록 보기

2/34

✔ 스프링 프레임워크

프레임워크, 뼈대나 근간을 이루는 코드들의 묶음. 프레임워크를 이용한다는 의미는 프로그램의 기본 흐름이나 구조를 정하고, 모든 팀원이 이 구조에 자신의 코드를 추가하는 방식으로 개발하게 된다.

장점 : 개발에 필요한 구조를 이미 코드로 만들어 놓았기 때문에, 실력이 부족한 개발자라도 반쯤 완성된 상태에서 필요한 부분을 조립하는 형태의 개발이 가능하다.

✔ 스프링의 주요 특징

POJO 기반의 구성 : Plain Old Java Object, 객체 간의 관계를 구성할 수 있는데 이때 다른 프레임워크들과 달리 API등을 사용하지 않고 POJO의 구성만으로 가능하도록 제작되어 있다. 이는 일반적인 형태로 코드를 작성하고 실행할 수 있어 생산성에도 유리하고, 코드 테스트 작업도 유연하게 할 수 있다.
의존성 주입(DI)과 스프링 : ApplicationContext가 필요한 객체들을 생성하고, 필요한 객체들을 주입하는 역할을 해주는 구조. 기존의 프로그래밍과 달리 객체와 객체를 분리해서 생성하고 이러한 객체들을 엮는 작업을 하는 형태의 개발이 된다. 스프링에서는 ApplicationContext가 관리하는 객체들을 Bean이라는 용어라 부르고 빈과 빈 사이의 의존관계를 처리하는 방식으로 XML 설정, 어노테이션 설정, Java 설정 방식을 이용할 수 있다.
스프링에서는 생성자를 이용한 주입과 setter 메서드를 이용한 주입으로 의존성 주입을 구현한다. 설정 방식은 주로 XML이나 어노테이션을 이용해서 처리한다.
AOP의 지원 : 반드시 처리가 필요한 부분을 스프링에서는 '횡단 관심사(cross-concern)'라 부른다. Aspect Oriented Programming은 이러한 횡단 관심사를 모듈로 분리하는 프로그래밍의 패러다임이다. 스프링은 AOP의 AspectJ의 문법을 통해 작성할 수 있는데, 이를통해 개발자는 핵심 비즈니스로직에만 집중할 수 있고, 각 프로젝트마다 다른 관심사를 적용할 때 코드 수정 최소화가 가능하며, 원하는 관심사의 유지보수가 수월한 코드를 구성할 수 있다.
트랜잭션의 지원 : 데이터베이스를 이용할 때 반드시 신경써야되는 부분은 하나의 업무가 여러 작업으로 이루어 지눈 경우의 트랜잭션 처리이다. 이 트랜잭션 관리를 어노테이션이나 XML로 설정할 수 있기 때문에 개발자가 매번 상황에 맞는 코드를 작성할 필요가 없다.

✔ 스프링의 작동 순서

스프링 프레임워크가 시작되면서 먼저 스프링이 사용하는 메모리 영역(Context: ApplicationContext)을 만든다.
스프링은 자신이 객체를 생성하고 관리해야 하는 객체들에 대한 설정이 필요하다. (root-context.xml)
root-context.xml에 설정되어 있는 <context:component-scan> 태그의 내용을 통해서 'org.zerock.sample' 패키지를 스캔하기 시작한다.
해당 패키지에 있는 클래스들 중에서 스프링이 사용하는 @Component라는 어노테이션이 존재하는 클래스의 인스턴스를 생성한다.

✔ 용어 정리

@ContextConfiguration : 지정된 클래스나 문자열을 이용해서 필요한 객체들을 스프링 내에 객체로 등록하게 된다. 'classpath:'나 'file:'을 이용할 수 있으므로, 이클립스에서 자동 생성된 root-context.xml 경로로 지정할 수 있다.

@Log4j : 로그를 기록하는 Logger 변수로 생성한다. Log4j 라이브러리와 설정이 존재하면 Logger 객체의 선언은 안해도 된다.

@Autowired : 인스턴스 변수가 스프링으로부터 자동으로 주입해 달라는 표시.

Junit Test 로 테스트 코드 결과 확인 가능.

Lombok: 컴파일 시 흔하게 코드를 작성하는 기능들을 완성해주는 라이브러리. @Setter 어노테이션은 setter 메서드(value, onMethod, onParam)를 만들어주는 역할.

Oracle : 관계형 데이터베이스. 맥북에서 이용하려면 Docker를 통해 설치 실행하는게 좋다. 오라클 설정에서는 SQL Developer과 연결이 가능해야하고 JDBC 연결 테스트와 스프링 연동 테스트도 가능해야 한다.

JDBC : 자바에서 데이터베이스에 접속할 수 있도록 하는 자바 API이다. JDBC는 데이터베이스에서 자료를 쿼리하거나 업데이트하는 방법을 제공한다.

커넥션 풀 : 여러명의 사용자를 동시에 처리해야 하는 웹 어플리케이션의 경우 데이터베이스 연결을 이용할 때는 '커넥션 풀'을 이용한다. Java에서는 DataSource라는 인터페이스를 통해서 커넥션 풀을 사용한다. (Ex: spring-jdbc 라이브러리, HikariCP)

MyBatis : SQL 매핑 프레임워크, JDBC 코드의 복잡하고 지루한 작업을 피하는 용도로 많이 사용한다.

MyBatis-spring : Mapper 인터페이스를 이용해서 실제 SQL 처리가 되는 클래스를 자동으로 생성한다. 인터페이스와 SQL만을 작성하는 방식으로도 모든 JDBC 처리를 끝낼 수 있다.

@Override :자바 1.5부터 생긴 어노테이션인데, 문자 그대로 메소드를 오버라이드를 한다는 것을 명시하는 것이다. 상속 관계에 있는 두 클래스 중, 하위 클래스에서 상위 클래스의 메소드를 재정의하는 것을 의미.

어노테이션 : 자바 코드에 @를 이용해 기능이 있는 주석을 달아 의미를 부여한것. 쉬운 데이터의 유효성 검사와 깔끔한 코드에 도움을 준다. 또한 메타-데이터

메타-테이터 : 데이터를 위한 데이터, 한 데이터에 대한 설명을 의미하는 데이터. (자신의 정보를 담고 있는 데이터)

✔ 스프링 MVC

스프링 MVC는 스프링의 서브 프로젝트이다.
스프링 MVC를 구성해서 사용한다는 의미는 내부적으로는 root-context.xml로 사용하는 일반 Java 영역(POJO)과 servlet-context.xml로 설정하는 Web 관련 영역을 같이 연동해서 구동하게 된다.
로딩 구조 : 프로젝트 구동시 web.xml은 Tomcat 관련 설정, root-context.xml과 servlet-context.xml은 스프링 관련 설정이다.
스프링 MVC를 이용하면 Servlet/JSP의 API (HttpServletRequest, HttpServletResponse)등을 작성안하고도 기능 구현이 가능하다.

✔ 스프링 MVC의 기본 구조

MVC는 모델2 방식으로 처리 : '로직과 화면을 분리' - 사용자의 Request는 Controller를 먼저 호출 (나중에 View를 교체하더라도 사용자가 호출하는 URL자체에 변화가 없게 만들어주기 위해), 컨트롤러는 데이터를 처리하는 존재를 이용해서 데이터(Model)를 처리하고 Response할 때 필요한 데이터(Model)를 View쪽으로 전달한다.

사용자의 Request는 Front-Controller인 DispatcherServlet을 통해서 처리.
HandlerMapping은 Request의 처리를 담당하는 컨트롤러를 찾기 위해 존재.
컨트롤러가 찾아졌다면 Handler Adapter를 이용해서 해당 컨트롤러를 작동.
컨트롤러는 개발자가 작성하는 클래스로 실제 Request를 처리하는 로직을 작성하게 된다. 이때 View에 전달하는 데이터는 주로 Model이라는 객체에 담아 전달, 컨트롤러는 다양한 타입의 결과를 반환하는데 이에 대한 처리는 ViewResolver를 이용.
ViewResolver는 컨트롤러가 반환한 결과를 어떤 View를 통해서 처리하는 것이 좋을지 해석하는 역할.
View는 실제로 응답 보내야 하는 데이터를 JSP 등을 이용해서 생성하는 역할을 하게 된다. 만들어진 응답은 DispatcherServlet을 통해서 전송.

✔ 스프링 MVC의 Controller

컨트롤러의 메서드가 사용할 수 있는 리턴타입
하나의 클래스 내에서 여러 메서드를 작성하고, @RequestMapping등을 이용해서 URL을 분기하는 구주로 작성할 수 있기 때문에 하나의 클래스에서 필요한 만큼 메서드의 분기를 이용하는 구조로 작성한다.

String : jsp를 이용하는 경우에는 jsp파일의 경로와 파일이름을 나타내기 위해 사용
void : 호출하는 URL과 동일한 이름의 jsp를 의미
VO, DTO 타입 : 주로 JSON 타입의 데이터를 만들어서 반환하는 용도로 사용
ResponseEntity 타입 : Response할때 Http 헤더 정보와 내용을 가공하는 용도로 사용
HttpHeaders : 응답에 내용 없이 Http 헤더 메시지만 전달하는 용도로 사용

특징 :

HttpServletRequest, HttpServletResponses를 거의 사용할 필요 없이 필요한 기능 구현
다양한 타입의 파라미터 처리, 다양한 타입의 리턴 타입 사용 가능
GET 방식, POST 방식 대신에 어노테이션만으로도 필요한 설정 가능
기본적으로 Java Beans 규칙에 맞는 객체는 다시 화면으로 객체를 전달.

어노테이션 :
@Data 어노테이션으로 getter/setter, equals(), toString()등의 메서드를 자동 생성한다.
@RequestMapping 어노테이션으로 method속성을 추가 할 수 있다. method 속성은 흔히 GET 방식, POST 방식을 구분해서 사용할 때 이용한다.
@RequestParam 어노테이션은 파라미터로 사용된 변수의 이름과 전달되는 파라미터의 이름이 다른 경우 유용하게 사용할 수 있다.
@InitBinder 변환이 가능한 데이터는 자동으로 변환되지만 경우에 따라서는 파라미터를 변환해서 처리해야 하는 경우도 있다. 이때 사용하는게 InitBinder 어노테이션.

✔ 스프링 MVC의 Model

Model 객체는 JSP에 컨트롤러에서 생성된 데이터를 담아서 전달하는 역할을 하는 존재. Model을 사용해야 하는 경우는 주로 Controller에 전달된 데이터를 이용해서 추가적인 데이터를 가져와야 하는 상황.
(ex: 리스트 페이지 번호를 파라미터로 전달 받고, 실제 데이터를 View로 전달해야 하는경우, 파라미터들에 대한 처리 후 결과를 전달해야 하는 경우)

@ModelAttribute 는 강제로 전달 받은 파라미터를 Model에 담아서 전달하도록 할 때 필요한 어노테이션. 타입에 관계없이 무조건 Model에 담아서 전달되므로, 파라미터로 전달된 데이터를 다시 화면에서 사용해야 할 경우에 유용하게 사용된다.

RedirectAttributes는 Model과 같이 파라미터로 선언해서 사용하고, 일회성 데이터를 전달하는 용도로 사용된다.

✔ Controller의 예외 처리

@ExceptionHandler : 해당 메서드가 () 들어가는 예외 타입을 처리한다는 것을 의미. 속성으로는 Exceoption 클래스 타입을 지정할 수 있다.
@ControllerAdvice : AOP(Aspect-Oriented-Programming)을 이용하는 방식, 공통적인 예외사항에 대해서는 별도로 분리 하는 방식.