다시돌아온 간략한 스프링정리시간

2019-03-12

Spring

IoC?

의존성이 뒤바뀐것. 어떻게 바뀐거야?
내가 만드는것이 아니라 밖에서 넣어주는 형태

class ShController {    
   private ShRepository repo;

   public ShController(ShRepository repo) {        
     this.repo = repo;    
   }  
 }

IoC 컨테이너

ApplicationContext 는 IoC 컨테이너로써 우리가 직접 쓸 일은 거의 없다(Spring boot에서)
빈들을 만들고 빈들의 의존성을 엮어주는 역할을 한다. (객체생성 관리등…)

@Autowired
ApplicationContext applicationContxt;
.....
applicationContxt.getBean(A.class); //객체를 가져올 수 있다.

빈

스프링 IoC가 관리하는 객체이다. 즉 ApplicationContext안에서 관리되는 객체
인터페이스도 빈이 될수 있을까? 그렇다.

빈을 등록하는 방법은?

빈을 쓰기위해서는 그것(클래스) 또한 빈이어야 한다.
why? 빈만 빈을 쓸 수 있다/

1.@ComponentScan
얘가 @Component인 애들을 찾아 빈으로 등록한다. @Controller은 왜 빈으로 인식되는거야? @컨트롤러 코드를 열어보면 @Componet로 되어있다. 즉 같은것으로 볼 수 있다.

2.XML이나 자바 설정 파일에 등록

3.직접 등록하는 방법

이때는 @Configuration 이라는 애노테이션을 갖고있는 클래스에서 등록이 이뤄져야 한다.

@Configuration
class BeanTest{
  @Bean
  public String sh(){
    return "sh";
  }
//String type의 빈을 하나 등록.
}

public class AController{
  @Autowired
  String sh;  //sh가 들어간다        
}

의존성 주입

@Autowired , @Inject이라는 어노테이션을 활용하여 의존성을 주입한다.

어떤 빈에 생성자가 하나만있고 생성자의 매개변수 타입이 빈으로 등록되어있다면 빈을 주입해준다.@Autowired가 없더라도..즉 아래와 같은 형태

public class AController{
  private final ARepository aRepository;
  private final BRepository bRepository;

  //방법 1
  //@Autowired 없어도 됨.(있어도 됨)
  public AController(ARepository aRepository,BRepository aRepository) {
    this.aRepository = aRepository;
    this.bRepository = bRepository;
  }

}

의존성 주입하는 두번째 방법

public class AController{
  @Autowired
  private final ARepository aRepository;

  @Autowired
  private final BRepository bRepository;
}

즉 위의 두가지 모두 의존성이 주입된다고 볼 수 있다.

@Autowired , @Inject은 어디에 붙이는것이 좋은가?

클래스에 반드시 필요한 객체일경우 생성자로 의존성주입하는것이 좋다.
세터가 있다면 세터에 붙이고
세터가 없다면 필드에 붙이는것이 좋다.

AOP

흩어진 코드를 한곳으로 모아라

AOP를 구현하는 기법

바이트 코드를 조작하는방법
컴파일을 하면 .class가 나오는데 이를 조작하는것. 컴파일된 코드안에 공통되는 부분을 끼워넣는 방법
프록시 패턴을 사용하는 방법
A 클래스를 상속받아
class AProxy extends A{ }
안에서 공통되는 부분을 호출하는것.

사방으로 흩어진 코드를 한곳으로 모으고 다른 클래스들은 자신의 일만 하도록 하는것
즉 Single Response Principle에 적합하게 코딩하도록 도와주는 코딩기법.

PSA Portable Sevice Abstract

잘만든 인터페이스라 보자.
어떤 기술에 특화되어있는 코드, 확장성이 좋지 않은 코드를 쓰면 테스트를 만들기도 어렵고 기술이 변경될 때 마다 코드를 변경해야 한다. 잘만든 인터페이스를 활용한다면 테스트하기도 좋고 바꿔끼기도 좋다.

어노테이션의 정의가 바뀌더라도 우리는 그대로 쓸 수 있다!

Web/AppSpring