DI 방식, FIlter / Interceptor / AOP

>>DI의 방식 중 필드 vs 생성자 주입 방식

 💡 DI는 객체간의 결합도를 줄여 의존관계를 느슨하게! →유연한 대처가 가능

DI의 방식

필드 주입

의존성을 나타내는 필드에 @Autowired어노테이션을 사용해서 주입

• 코드 작성이 간결
• 오류를 찾기 어렵고 의존성 주입의 순서를 보장하기 어려움

생성자 주입

의존성을 주입하는 생성자를 정의하고, @Autowired 어노테이션을 사용하여 의존성을 주입

• 오류를 찾을 수 있고, 의존성 주입의 순서를 보장
• 생성자를 통한 필수 의존성을 전달하므로, 의존성 누락에 대한 예방 가능
• 권장되는 방법(불변성 확보, 테코 작성, final 키워드 작성 및 lombok과 결합, 순환참조 에러 발생 방지(스프링 2.6미만))

예시

필드 주입 & 생성자 주입

//필드 주입
public class PostService {
	@Autowired
	private PostRepository postRepository;
}

//생성자 주입
public class PostService {
	private final PostRepository postRepository;
	@Autowired
	public PostService (PostRepository postRepository) {
		this.postRepository = postRepository;
	}
}

---

프로퍼티를 통한 의존성 주입

• applicationContext.xml에 <property> 태그를 사용하여 의존성을 주입 →객체 생성 시 주입된 객체도 함께 생성됨

 

인터페이스를 통한 의존성 주입

• 추상화 개념을 이용한 의존성 주입 방식
• 의존성을 주입하는 대상 클래스가 인터페이스를 구현하고 있어야 함. 이 때, 구현체 클래스를 직접 주입하는 대신, 해당 인터페이스를 주입함으로써 유연성과 확장성을 높일 수 있다.
• **ex>**서비스 클래스가 데이터베이스와 의존성을 가지고 있다고 가정. 서비스 클래스는 데이터베이스와 직접적으로 의존하므로 인터페이스를 이용한 의존성 주입 방식을 적용하면, 서비스 클래스는 인터페이스를 의존하도록 변경할 수 있다. 이렇게 하면, 추후에 데이터베이스를 변경하더라도 서비스 클래스의 코드를 수정하지 않아도 됨. →최종 프로젝트에 적용했던 방식…

 

의존성 주입 순서의 중요성...

• Null 포인터 예외 방지: 의존성이 있는 객체를 생성하기 전에 의존성이 있는 객체를 먼저 생성하면 Null 포인터 예외를 방지할 수 있습니다. 의존성이 있는 객체를 먼저 생성하지 않으면 Null 값을 가진 상태에서 의존성이 있는 객체를 생성하려 할 때 Null 포인터 예외가 발생할 수 있습니다.
• 객체의 무결성 보장: 의존성이 있는 객체를 먼저 생성하고 주입하는 것은 객체의 무결성을 보장하는 데 도움이 됩니다. 의존성이 있는 객체를 생성하고 주입하기 전에 의존성이 있는 객체의 상태가 올바른지 확인하고, 이후에 의존성이 있는 객체를 생성하고 주입하면 객체의 무결성을 보장할 수 있습니다.
• 모듈화된 코드 작성: 의존성 주입 순서를 정해놓으면 코드를 모듈화할 수 있습니다. 의존성이 있는 객체를 먼저 생성하고 주입하는 코드는 의존성이 있는 객체와 의존성이 있는 객체를 사용하는 객체를 분리할 수 있습니다. 이는 코드를 더욱 간결하고 유지보수하기 쉽게 만들어줍니다.

 

---

>>Filter / Interceptor / AOP 이 3가지의 정의와 차이점

웹개발을 하다보면 공통적으로 처리해야 할 것들이 생김 (ex. 로그인처리, 권한체크 등…) →공통업무에 관련된 코드를 페이지별로 작성한다면 중복코드 발생 , 서버 부하 , 유지 보수 어려움 등의 문제가 발생한다.

 

즉, 공통된 업무는 따로 빼서 관리를 하는게 적합!

Spring 에서는 이럴 때 3가지 방법이 존재한다. → Filter / Interceptor / AOP

흐름

• Filer, Interceptor, AOP는 각각의 역할을 수행하며 특정 상황에서 필요에 따라 조합해서 사용.
• 요청 → request > filter > Servlet > Interceptor > AOP > Controller 순서로 실행.
• Interceptor, AOP, Controller : Spring Context Filter : Web Context

공통점

▪ 애플리케이션에서 요청 처리를 조작하고, 제어할 수 있는 기능을 제공한다. ▪ 애플리케이션의 로직을 제어하고, 코드의 중복을 제거하고, 코드의 유지보수성을 높이는 데에 기여할 수 있는 공통적인 목표를 가지고 있다.

 

Filter

 💡 Filter는 서블릿 컨테이너에서 제공하는 기능(스프링 독자적 기능 X)으로, HTTP 요청을 가로채서 요청과 응답에 대한 정보를 조작하거나, 필터링하여 요청을 처리하는 기능을 수행합니다.

 

• 스프링 컨텍스트가 아니라 웹 컨텍스트에 속하며, 스프링 컨테이너가 아니라 웹컨테이너(톰캣) 에 의해 관리
• 웹 어플리케이션에서 클라이언트의 요청을 처리하기 전후로 요청과 응답을 변경하거나 처리하는 역할
• 모든 서블릿에 대해 적용이 되므로 로그인 여부, 인코딩 처리, 파일 업로드 등의 공통 로직을 처리할 때 주로 사용.
• FilterChain을 통해 여러 필터를 연쇄적으로 동작하게 할 수 있다.

Interceptor

💡 인터셉터(Interceptor)는 스프링에서 AOP(Aspect-Oriented Programming)을 구현하기 위한 기술 중 하나로, 컨트롤러(Controller)에 들어오는 요청(Request)과 컨트롤러가 반환하는 응답(Response)을 가로채서 필요한 처리를 할 수 있도록 하는 인터페이스입니다.

• 컨트롤러 실행 전후의 요청과 응답을 가로채서 처리
• 핸들러 실행 전/후에만 적용이 되므로 컨트롤러에서만 처리하도록 구현된 로직이나 권한체크와 같은 비즈니스 로직을 처리할 때 사용

AOP

 💡 AOP는 Aspect Oriented Programming의 약어로, 관점 지향 프로그래밍이라고 번역됩니다. AOP는 OOP(Object Oriented Programming)의 한계를 극복하고, 객체지향 개발을 보완하는 프로그래밍 패러다임입니다.

• 애플리케이션 전체에서 적용되는 공통 로직을 분리 → 개발을 용이하게 하는 기술
• 로깅, 보안, 트랜잭션 초리 등에 사용
• 프록시를 이용하여 타깃객체의 메소드 호출을 가로챔 → Filter나 Interceptor와는 다른 방식으로 동작한다.

 

---

https://www.notion.so/836f45337cdd4eebb5e544133e94ab17

...예시 작성해야 함.....

(추가공부…)Dispatcher Servlet / sevlet / requestParam / Tomcat, Thymeleaf