IT's 잡탕찌개 블로그

Spring ApplicationContext란 무엇인가?
Spring에서 IOC Container를 BeanFactory라고 하며 이 BeanFactory에 여러 기능이 추가된 class를 ApplicationContext라고 한다.

Bean Factory는 SpringContainer의 최상위 interface로 spring bean 을 관리 및 조회하는 역할을 한다.
BeanFactory를 기반으로 ApplicationContext에 추가된 부가기능으로는 환경변수 관련 처리, Application의 event를 발생시킬 수 있으며, 다양한 리소스를 읽는 등 여러 기능이 존재한다.

Application Context가 bean요청을 처리하는 과정
0. application context는 @configuration 이 붙은 class는 설정파일 정보로, @Bean, @Component가 붙은 method는 method 이름으로 bean 목록을 작성한다.
1. client가 특정 bean을 요청한다.
2. application context는 현재 등록된 bean 목록에서 해당 이름의 bean이 존재하는지 확인한다.
3. application context는 설정 class로부터 bean 생성 요청 및 생성된 bean객체를 반환한다.

Application Context를 사용하여 SpringFramework가  얻는 장점
. @Configure Annotation을 통해 설정과 관련된 class를 구분, 관리할 수 있다.
. 설정 class를 구분함으로써 client는 구체적인 설정 class를 알 필요가 적어진다.
. Application Context를 통해서 전반적인 IOC 서비스를 제공할 수 있다.
. Application Contextㄹ르 통해서 다양한 Bean을 검색할 수 있다.

Spring ApplicationContext에 등록된 Bean
Application Context에 등록된 Bean의 경우 기본적으로 Singleton으로 관리된다.
Spring에서 여러 Bean을 요청할 시 모든 요청에 대해 활용되는 객체는 단일 객체이며,
이로 인해 여러번 요청이 오더라도 매 요청마다 새로운 Bean 객체를 생성하지 않고 단일 객체를 활용한다.
(MultiThread에서 해당 Bean을 공유한다고 한다.)

Java를 통해 직접 Singleton객체를 만들 때 단점은 아래와 같다.
. private 생성자를 지녀 상속이 불가능하다.
. server 환경에서는 singleton이 1개만 생성됨을 완벽히 보장하지 못한다.
. static 상태를 만들 수 있기때문에 객체지향적이지 못하다.

이에 반해서 Spring 이 직접 Singleton 객체를 만들고 관리하는데, 이를 Singleton Registry라고 부른다.
Singleton Registry의 장점은 아래와 같다.
. static method나 private 생성자 등을 사용하지 않아 좀더 객체지향적 개발이 가능하다.
. test를 하기에 편하다.

다만 Bean 객체 정의 시 주의할점이 존재한다
. Bean 객체가 singleton으로 관리되기 때문에 각 객체는 내부에 상태정보를 지니면 안된다.
-> stateless 를 유지해야 함.
-> multi thread 환경에서 특정 상태를 지니면 위험소지가 존재.


참고 포스트
. https://mangkyu.tistory.com/151

spring에서의 IOC를 사용하는 이유는 어떤 것이 있을까?
객체지향 원칙을 준수하며 객체관리를 framework에 위임하고 개발자가 구현하려는 부분으로
각각의 역할을 분리해 응집도를 높이고 결합도를 낮추어 변경에 유연한 구조를 유지할 수 있기 때문이다.
즉, 추상 class와 구현 class를 만든 뒤 추상 class를 주입 받도록 하여 개발자는 비즈니스 로직에만 집중할 수 있게 된다.

spring에서의 IOC 원리
특정 instance 가 필요할 때 IOC container에서 Bean으로 등록된 class를 확인하여 instance를 생성한다.
그 후 해당 instance 가 필요한 다른 Bean 객체에서 요청 시에 이를 자동으로 주입해준다.

spring에서의 DI 방식은 아래의 3가지 방식이 존재하며 이에 대한 자세한 포스팅은 추후에 다루기로 한다.
. 생성자 주입
. setter 주입
. field 주입

spring의 IOC container
spring에서 IOC를 수행하는 component를 Ioc container 혹은 spring container라고 부른다.
spring container는 객체를 생성, 객체간의 관계를 연관, 객체의 생명주기를 담당한다.
즉, spring container는 의존성을 주입하고 각 객체들끼리 연관지어 Spring application 을 동작할 수 있게 해준다.

spring bean란
spring bean 이란 개념은 Ioc container가 관리하는 오브젝트들을 의미한다.

Spring ApllicatioContext
Spring 에서 ioc container의 역할을 담당하는 bean factory에 여러 기능이 추가된 것 이다.
@Component Annotation을 사용하면 해당 class를 component scan을 통해서 Bean으로 등록해준다.
Spring ApplicationContext에 대해서는 추후에 더 자세하게 다룰 예정이다.

spring 을 공부하면 필연적으로 듣게 되는 단어가 있다

바로 IOC 이다.
IOC는 Inverse of control 이라는 의미로 "제어의 역전"이라는 의미이다.
IOC는 코드의 제어가 유저에게 있는것이 아닌 framework 등 제 3자에게 위임되는 것을 의미한다.
쉽게 예를 들어보자.

class A
{
 public void callMe()
 {
  ....
 }
}

현재 사용하는 framework가 A라는 class의 함수를 내부에서 호출한다고 가정해보자.
즉, 해당 class에 대해서 함수의 호출 혹은 객체 생성등을 framework가 제어하고 있는 상태이다.
이러한 상황에서 우리가 A에 대한 callMe함수 오버라이딩 등을 통해서 정의한다면 해당 코드에 대해서는 framework가 직접 제어하는 상황이 되는 것이다. (DI에 대해서는 추후에 다룰 예정)

IOC의 실제 사용 예는 대표적으로 아래의 예가 존재한다
. Template Method
. DI ( Dependency Injection )
. Strategy Pattern
. Factory Pattern
. Service Locator

DI (Dependency Injection )
DI란 의존성을 주입하는것을 의미한다.
Ioc를 구현하기 위해 사용되는 대표적인 design pattern 중 하나로 특정 객체의 의존 관계를 객체의 외부에서 주입시키는 패턴이다.
전통적인 구현방식에서는 특정 A class에 대한 정의 후 A를 호출하는 식으로 프로그램이 구현된다.
하지만 DI의 경우, 우리가 A를 재정의한 A`를 정의하면 A에 대한 호출은 이미 외부에서 선언이 되어 있는 상태이기 때문에 A`의 code 가 호출된다.

DI는 어떤 조건을 지켜야 만족하는 것인가?
. class code 혹은 class model에서는 의존 관계가 노출되지 않는다.
. runtime 시점의 의존관계는 factory 등의 제 3의 존재가 결정한다.
. 의존관계는 object에 대한 레퍼런스를 외부에서 주입함으로써 만들어진다.

public class A
{
  prviate B b;
  
  public A()
  {
    b = new B();
  }
}

public class C
{
  private D d;
  public C(D d)
  {
    this.d = d;
  }
}

위의 코드 중 A에 대한 내용을 살펴보자.
A의 내부에선 B에 대한 객체 생성을 진행하며 이를 내부 변수로 지닌다.
이 과정은 DI라고 볼수 없는데 우선 B의 생성자가 A에서 호출되기 때문에 추후에 B의 생성자가 변경될 시 A가 영향을 받는 문제가 존재한다.
또한 위의 code를 보면 A는 B를 생성한다는 점에서 사실상 B와 A가 class 수준으로 관계가 생긴것으로 볼 수 있다. 이 점에선 위의 DI가 지켜야할 조건중 하나를 지키지 못한것으로 볼 수 있다.
반면, D와 C의 경우를 살펴보면 C는 외부에서 D에 대한 객체를 전달 받는 것을 볼 수 있다.
이렇게 객체를 전달 받으면 C는 D의 레퍼런스를 전달 받는다.
D와 C는 객체에 대한 의존을 갖고 class 수준의 관계는 맺지 않으며, 의존관계는 외부에서 주입당하여 만들어진다. 또한 runtime 시에 외부에서 의존관계를 지정하기때문에 DI에 필요한 조건들을 만족한다.

위의 예에서는 생성자를 통해 D를 전달 받기는 했지만 의존성은 setter 함수 혹은 interface 구현을 통해서도 삽입 될 수 있다.

public class SetterA
{
  private B b;
  ....
  public void setB(B b)
  {
    this.b = b;
  }
}

public class InterA extends injectorB
{
  private B b;
  @Override
  public void injection(B b)
  {
    this.b = b;
  }
  ...
}

interface injectorB
{
  void injection(B b);
}

이렇게 setter와 interface를 사용하여 의존성을 주입할 수 있지만 setter의 경우 함수 정의를 누락할 여지가 있다.

SpringBoot 에서 작업을 하다보면 Bean과 Component 라는 Annotation을 자주 볼 것이다.
위의 두 Anootation이 어떠한 역할을 하는지, 어느점이 다른지에 대해서 알아보자.

우선 IOC라는 개념이 있다
Inherited Oriented Class의 약자이다( 뻥이고 사실 Inversion Of Control의 약자이다.)
간단하게 말하자면 일종의 제어관계의 역전 이라는 의미인데 기존의 우리가 프로그래밍을 할 시
어떠한 class를 설계하고 해당 class를 code에서 직접 호출하고 관련 함수를 활용하여 output을 얻는다.
이러한 개념과 반대로 IOC는 지정된 방식을 사용하여 코드를 작성하면 code의 호출과 제어를 framework가 자동으로 진행하는데 이러한 특징 때문에 Inversion of control 이라고 부른다.
우리가 알아볼 Bean, Component, 그외 다른 Annotation 은 해당 class, method가 어떠한 역할을 하는지에 대한 meta정보 라고 생각하면 된다.

Bean Annotation
. Bean Annotation의 경우 서드파티나 사용자가 정의하지 않은 객체에 대해서 IOC에 등록(?)하고자 할 때 사용된다.
. 간단한 예 : User 객체를 반환받는 함수 정의

......

@Bean
public User getUser()
{
 ....
  return User.builder()
      .name("test")
      .build()
  ;
}

위의 code block을 보면 User객체를 사용자가 가공한 후 반환하는 것을 볼 수 있는데 해당 User객체는 springboot에서 기본적으로 제공하는 User class이다.
위처럼 User 객체를 가공 후 넘겨주는 code를 작성한 후 Bean을 지정하면, IOC에 의해서 User 를 사용하는 내부 구현에서 위의 함수를 호출하여 User 객체를 활용하게 된다.
=> 즉, 개발자가 직접 User객체를 사용하는 상위 함수를 구현하지 않아도 User를 쓰는 부분에선 해당 함수를 통해서 알아서 사용한다는 의미.

Component Annotation
. Component Annotation의 경우 Bean과 달리, 사용자가 직접 정의한 class에 대해서 IOC를 적용하기 위한 Annotation 이다.
. 대표적인 Component Annotation 으로는 Controller, Service, Repository 등이 있다.
-> 해당 Annotation 들 내부에 Component가 정의되어 있음.

우선 각 용어별로 간단하게 알아보자
우리가 많이 사용하는, 또는 많이 사용하게 될 Springboot는 Spring, SpringMVC와 많이 볼 수 있다.

인터넷에서 찾아본 각각의 대한 설명을 한번 살펴 보자.

Spring 이란?
. java 기반의 web app을 개발을 위한 오픈 소스 framework 이다.

SpringMVC 란?
. web app 개발에 있어서 MVC 패턴을 적용할 수 있게 spring에서 제공하는 framework 이다.

SpringBoot 란?
. web app 개발 시 필요한 설정 방식, 구현 방식등을 자동화, 제공하는 spring 기반의 framework이다.

위의 각 설명을 보면 spring, springMVC, springboot가 사실 구분이 필요한 것들이라는 것을 알 수 있다.

springboot와 springMVC의 공통점
. 둘다 모두 spring 기반의 framework이다.
. 구현방식에 있어서 사실 springboot가 초기 의존성에 spring-web을 포함하므로 사실상 MVC 구조로 구현된다고 볼 수 있다.
-> spring-web에 springMVC가 포함되어 있음.

springboot 와 springMVC의 차이점
. springboot는 기본 설정등이 자동화가 되어 있어 개발자가 불필요한 설정 작업을 하지 않도록 도와준다.
. 반면, springMVC의 경우 Dispatcher Servlet, HandlerMapping 등의 xml 파일에 직접 설정을 해야 한다.
. servlet 기반의 app을 싱행시에는 WAS가 필요한데 springMVC의 경우는 포함되어 있지 않지만, Springboot의 경우 기본적으로 Tomcat이 포함되어 있어 추가적인 설치가 필요하지 않다.


그렇다면 SpringBoot를 안 써본 사람은 굳이 springBoot를 써야하는 이유가 있을까?
현재 나처럼 SpringBoot를 배우는 입장으로써, 그리고 인터넷에서 알아본 사항들에 있어서 어떠한 장점으 있는지 아래 내용을 보자.

우선 SpringBoot는 의존성에 대한 부분을 알아서 관리, 권장해준다.
spring의 경우 xml 파일에 dependence에 대한 사양 정보를 각 버전까지 일일히 명시하고 관리해야 하지만,
SpringBoot의 경우는 단순히 어떠한 모듈을 사용할지 명시만 하면 의존성 주입이 완료된다.
-> 아직 spring과 springboot로 장기적인 project 관리를 해보진 않았지만 장점이면서 단점이 될것같다
-> 추측이긴하지만 springboot의 경우 모듈의 버전이 올라갔을 때 대대적인 변경사항이 발생하면 해당 부분에 대해서 바로 코드 수정 및 배포작업이 필요하지 않을까?

그 외 springboot의 장점으로는 spring-security, spring-data-jpa 등의 다른 framework를 간편하게 사용할 수 있게 한다는 점이다.

결론
. springboot와 springMVC는 각기 다른 개념이라서 각각에 대한 장단점을 비교하기에는 약간의 무리가 있다.
. springboot는 spring의 설정을 간편하게 해주는 framework, springMVC는 spring 기반의 web App개발용 framework이기 때문에 같은 위치,역할이 아니다.

ps : springboot, spring-web, spring-security 등을 사용하여개인 토이 프로젝트 진행중에 개념정리하려고 포스팅 함.

@SpriongBootApplication
 . Springboot 를 실행하기 위한 중요한 역할을 담당한다
 . Springboot의 기본적인 설정이 선언되어 있다.

@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Inherited
@SpringBootConfiguration
@EnableAutoConfiguration
@ComponentScan(excludeFilters = { @Filter(type = FilterType.CUSTOM, classes = TypeExcludeFilter.class),
		@Filter(type = FilterType.CUSTOM, classes = AutoConfigurationExcludeFilter.class) })
public @interface SpringBootApplication {
 ....
 }

위 처럼 여러가지 meta Annotation 을 포함한다.
 - meta annotation ; 다른 annotation 을 정의하는데 사용되는 annotation을 의미
 
@Target
 . java complier가 해당 annotation이 적용될 대상을 결정할 때 사용된다.
 . 위의 코드를 보면 @SpringBootApplicaction의 target을 type으로 지정하고 있다.
 . ElementType은 PACKAGE, TYPE 등등이 존재한다.
 
@Retention
 . 해당 Annotation이 실제로 적용되고 유지되는 범위, 즉 해당 annotation의 lifecycle을 의미한다.
 . RUNTIME, CLASS, SOURCE 3가지가 존재한다.
 . @Retention(RetentionPolicy.RUNTIME)
 - compile 이후에도 JVM에 의해서 계속 참조가 가능하다.
 . @Retention(RetentionPolicy.CLASS)
 - Complier가 class를 참조할 때까지 유효하다.
 . @Retention(RetentionPolicy.SOURCE)
 - Complire 전까지만 유효하며, complier 이후에는 사라지게 된다.
 
=> 좀더 자세히
 . JVM은 Java source(.java 파일)를 complier가 complie 후에 Java byte code(.class 파일)로 변환한다.
위의  SOURCE는 .java까지 annotation이 남아 있다는 것이고, CLASS는 .class 까지,
RUNTIME은 runtime 환경에서까지 남는다는 것이다.
RUNTIME 은 실행중에도 annotation의 정보를 확인할 수 있다.
SORUCE의 경우는 특정 byte code를 생성한 후 .class에서는 사라지기며, lombok의 Getter, Setter를 예로 들 수 있다.
CLASS의 경우 Maven / Gradle을 통해 다운 받은 lib등의 jar 파일에는 source가 포함되어 있지 않기 때문에 필요하다.
 
@Documented
 . javadoc으로 api 문서를 만들 때 annotation에 대한 설명도 포함하도록 지정하는 역할을 한다.
 
@Springbootconfiguration

@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Configuration
@Indexed
public @interface SpringBootConfiguration {
 .....
}

 . @Springbootconfiguration의 세부 사항을 보면 위의 코드와 같이 meta annotation으로 구성되어 있다.
이 중 @Configuration 이 중요한데 @Configuration 이 존재할 때 spring은 java configurure 설정 class로 간주하며 Bean으 로 등록하게 된다.

@Inherited
. 해당 annotation이 붙은 경우 자식 class까지 annotation을 상속하게 된다.
 

springboot 에서 cookie와 session 을 어떻게 사용하는지에 대해서 간단한 code를 통해 알아보자.

cookie의 추가

.....

@GetMapping("/tmp")
public String tmp(HttpServletRequest req, HttpServletResponse res)
{
  ....
  Cookie newCookie = new Cookie("cname", "cval");
  newCookie.setMaxAge(60); //60 seconds
  newCookie.setSecure(true);
  res.addCookie(newCookie);
  ......
  return "somthing";
}

 사용법은 단순하게 Cookie 생성 후 해당 Cookie의 각 속성에 대해서 지정한 후 response에 포함시켜 전달하면 된다.

cookie 내용 확인

....

@GetMapping("/tmp")
public String tmp(@CookieValue String email, @CookieValue("username") String username)
{
 //해당 Annotation 을 통해 접근 가능.
  return "something";
}

@GetMapping("tmp2")
public String tmp2(HttpServletRequest request)
{
 ....
 var cookies = request.getCookies();
 for(var coookie : cookies)
 {
   var cname= cookie.getName();
   var cval = cookie.getValue();
   // do something
 }
 return "something";
}

spring boot 에서는 위처럼 Annotation을 활용하거나 request에 직접 접근하여 cookie를 확인하는 방법이 존재한다.

session에 접근하기

.....

@GetMapping("tmp")
public String tmp(HttpServletRequest request)
{
 ....
 HttpSession session = request.getSession();
 //session에 특정 정보 추가하기
 session.addAttribute("someKey", "thisValue");
 ........
 
 return "something";
}


@GetMapping("tmp2")
public String tmp2(HttpServletRequest request)
{

  ......
  var session = request.getSession(false);
  //false인 경우 해당 요청에 session 이 존재하지 않을때 null을 반환
  if(session == null)
  {
    session = request.getSession(true);
    //true인 경우 session 이 없으면 새로운 session 을 생성& 반환.
  }
  return "smoethig";
}

@GetMapping("tmp3")
public String tmp3(@SessionAttribute(name="someKey", required=false) String thisValue)
{
  //session에 someKey에 대한 정보가 없는 경우 thisValue는 null
  
}

springboot에서는 위처럼 간단하게 session 정보에 대해서 접근 및 가공이 가능하다.