KOMAS

JAVA SE 위에서 동작하는 기업형 응용 프로그램 (JAVA EE or SPRING)

현재는 EE가 유료이므로, SPRING을 주로 사용한다.

스프링의 대표 기능

MVC(DI), TRANSACTION(AOP), 인증과 권한(FILTER)

DI와 IOC컨테이너

객체를 생성해주고 인터페이스를 통해 조립해준다.

bean으로 생성하고, 인터페이스에 맞는 bean을 주입한다.

✔ IOC(inversion of control) 컨테이너라고 하는 이유

(1) 기존 프로그래밍

A -> B -> C -> D

A에서 B객체를 생성, B에서 C 객체를 생성, C에서 D객체를 생성

(2) 스프링 컨테이너

D -> C -> B -> A

D를 C에 주입, C를 B에 주입, B를 A에 주입

IOC 컨테이너의 사용

ApplicationContext - 스프링 설정 지시서를 읽는 인터페이스

구현체

ClassPathXmlApplicationContext ( " 스프링 bean 설정.xml ")  // 지시서가 xml로 설정되어있는 경우

AnnotationConfigApplicationContext ( ConfigClass.class ) // @Configuration 지정 클래스

컨테이너에서 Bean을 사용하기

(1) class로 꺼내기: 참조 인터페이스 타입 = context.getBean(클래스.class)

* 구현체.class 를 적으면 구현체를 가져오고, 인터페이스를 적으면 인터페이스에 지정된 구현체를 가져온다.

(2) id로 꺼내기: 참조 인터페이스 타입 = (bean 형변환 필요) context.getBean("bean name")

의존 객체로 Bean을 사용하기

@Autowierd  - 생성자 주입, 필드 주입, setter주입 

* 인터페이스에 맞는 구현체 Bean을 사용한다.

@Qualifier("id") 

* Configuration에서 bean 생성, class에 @Component도 달아준 경우 (인터페이스에 맞는 Bean이 여러 개 일 때)

id로 지정해서 하나의 Bean만 사용할 수 있게 한다.

id를 지정하지 않았다면 맨 앞 클래스명을 소문자로 사용

XML - 생성자 주입, 필드 주입, setter주입 설정 필요

컴포넌트 스캔을 통해 어노테이션 지정 객체 생성

xml에서 Bean으로 등록되지 않은 클래스는 사용할 수가 없다.

@Component는 xml에 Bean으로 등록되지 않아도 스프링 컨테이너에 Bean으로 등록시킬 수 있다.

대신 xml에 <context: component scan base-package=" 베이스 패키지 "> 컴포넌트 스캔으로 Bean의 생성이 필요하다.

<context:annotation-config> 도 필요 없어진다.

<context:annotation-config> : 등록된 Bean에 대해서 어노테이션(@Autowired, @Qualifier) 활성화

Xml사용 없이 스프링 컨테이너의 관리 

@ComponentScan(" {base-package 패키지명, 패키지명 } ")  // 컴포넌트 스캔으로 Bean을 생성

@Configuration  //  내, 외부 라이브러리 Bean을 생성, 주로 외부 라이브러리 클래스 Bean 생성

@Bean  // 함수명이 id로 사용

반환 타입 class

return new 구현체

@Configuration
@ComponentScan({"com.ky.test"})
class Config{
    @Bean
    public RClass rc() {
        return new RClass();
    }
}

RClass로 생성해놓고, RClass가 구현하고 있는 interface에 @Autowired를 지정하면 자동 바인딩된다.

@Bean과 @Component 차이

@Bean - 외부 라이브러리 클래스를 Bean으로 등록할 때

@Component - 직접 설계한 class를 Bean으로 등록할 때

AOP

주 업무 로직과 공통 관점 로직을 분리하여 유지보수성, 응집도를 높인다.

로그 처리, 트랜잭션 처리, 보안 처리

Advice : 공통 관점 로직 적용 시점 - Befor, After, Around.. (어느 위치에 끼어들건지)

JoinPoint : 주 업무 로직 

PointCut : 적용 대상 JoinPoint 선별(위빙)

Weaving : 주요 관점에 공통 관점을 엮는 행위 

Aspect (Advisor) : 객체, 공통 관점 사항, Advice + PointCut (어떤 대상에, 어느 위치에)

 "(주 업무1)JoinPoint"에 "(PointCut1)"을 "weaving"하겠다. 

프록시를 이용한 aop 구현

xml

<proxy bean class="...ProxyFactoryBean" >

    <property name="target" ref= " aop 적용할 객체 ">

    <property name="interceptorNames">

        <list> 공통 관점 로직 구현 객체 </list>

공통 관점 객체는 인터페이스 구현 

MethodInterceptor - invoke 메서드 

MethodBeforeAdvice - before 메서드 

AtferReturningAdvice - afterReturning 메서드 ThrowsAdvice - afterThrowing 메서드 (처리할 예외 지정)

intellij 환경설정

프로젝트 설정: gradle project, web

톰캣 설정: add configuration - tomcat server - local - artifact 

* 톰캣 설정 후 gradle 빌드 설정

Artifact : 서버에서 실행할 파일, 프로젝트 결과물

archive

압축된 채로 배포, was에 의해 해제

한 개의 파일만 전송

exploded

압축 해제된 디렉터리 상태로 배포

원본 소스를 건드리지 않은 채로 배포

war, jar

https://server-engineer.tistory.com/315

프로젝트 설정 xml

web.xml

dispatcher-servlet.xml

applicationContext.xml

https://mrgamza.tistory.com/729

servlet/jsp와 스프링의 차이

(1) 톰캣.xml에는 dispatcher-servlet만 올리고, dispatcher-servlet.xml에서 servlet, service, mybatis, security 설정을 한다.

톰캣은 모든 URL을 dispatcher-servlet에게 전달한다.

(2) 기존 Dispatcher & Controller 기능이 합쳐진 여러 개의 HttpServlet을 구현한 Servlet 상태에서

하나의 Front Controller Servlet만 두고 jsp로 향하는 Dispatcher forward를 담당하게 하고,

Contoller는 POJO JAVA로 구성하여 Model 데이터 처리를 진행 후 Model, View를 Front Controller로 돌려주게 한다.

URL pattern

스프링에서는 모든 URL요청이 dispatcher-servlet을 통해 요청과 응답이 돼야 한다.

하지만, pattern을 " / "로 지정하고  "jsp 경로"로 요청하게 되면 jsp 화면을 바로 보여준다. view를 바로 보여주면 안 된다.

그래서 pattern을 " /* "로 지정하고 모든 요청이 dispatcher-servlet을 무조건 거치게 한다.

이 과정에서 WEB-INF 경로 안에 dispatcher-servlet.xml에 URL과 매핑된 bean 있어야 한다. (물론 어노테이션도 가능)

* <bean> - id /URL (실제 controller의 경로가 아닌 URL) , 클래스/implements Controller 

해당 빈은 URL이 요청되면 Controller 인터페이스 ModelAndView handlerRequest 메서드를 호출한다.

pattern을 " /* " 사용했을 때도 문제가 발생한다. ModelAndView에서 View를 보여줄 때 jsp파일을 한번 더 요청을 하게 되는데

이때는 jsp 파일 경로로 접근해야 되는데 모든 요청을 distpatcher-servlet을 타게 했으므로 문제가 발생한다.

그래서 pattern을 다시 " / "로 만들어주고, URL에 매핑되는 컨트롤러가 없다면 webapp 파일을 이용할 수 있게 한다.

URL 우선순위: URL은 매핑된 contoller가 있다면 contoller를 실행하고, 없다면 webapp 파일을 요청한다.

여기까지는 기존 " / " pattern과 같다.

view를 바로 보여줄 수 없도록 하는 방법으로 WEB-INF 경로가 등장했다.

WEB-INF

비공개 영역. URL 요청이 view로 바로 접근할 수 없도록 숨긴다.

숨기는 이유는 controller에서 요청을 받아 처리하고, 페이지를 보여줘야 한다. view 페이지로 바로 접근하면 안 된다.

클라이언트에서는 접근이 불가능하고, 서버 쪽에서는 접근이 가능하다.

View Resolver

view 파일들의 경로가 길어졌다. 이를 해결하기 위해 만들어짐. view 경로의 복잡성을 줄인다.

view를 찾을 때 절대 경로로 찾게끔 만들어둔다.

<bean class="org.springframework.web.servlet.view.InternalResourceViewResolver">
    <property name="prefix" value="/WEB-INF/views/"/>
    <property name="suffix" value=".jsp"/>
</bean>

static 파일

정적 파일들은 servlet이 아니기 때문에 default pattern도 뚫지 못하여, 경로로 요청해도 막힌다. (jsp는 되는데, html은 안되는 이유)

이를 해결하기 위한 방법이 있다.

설정하게되면 정적 파일을 클라이언트에서 요청할 수 있다.

<mvc:resources mapping="/**" location="/static/" />

기본적인 프로젝트 환경 설정이 완료되었다.