와 1장부터 진짜 내용이 너무 많아서 힘들었다......... 책에서 나온 개념들을 쭉 정리해보았다...
스프링 프레임 워크
스프링 프레임워크는 다양한 엔터프라이즈 애플리케이션을 개발하는 데 필요한 여러 기능을 제공하는 오픈소스 프레임워크이다.
IoC, AOP, 트랜잭션 관리, 메시징 등을 지원하여 애플리케이션 개발을 더욱 효율적으로 만들어 준다.
빈(bean)
스프링에서 빈(bean)은 IoC 컨테이너가 관리하는 객체를 의미한다. 빈은 스프링이 자동으로 생성하고 관리하는 객체로, 종속성 주입(DI) 방식으로 다른 객체에 의존성을 주입하거나, 특정 역할을 담당하는 객체로 사용된다. 스프링의 핵심 기능 중 하나는 객체를 IoC(제어의 역전) 방식으로 관리한다는 점이다. 객체간의 관계를 설정하고, 객체 생명주기 등을 스프링이 자동으로 관리해준다.
- 개념: 스프링이 IoC 컨테이너에서 관리하는 객체를 의미 한다. 일반적으로 싱글톤으로 관리되며, 스프링 설정 파일(XML 또는 어노테이션)에 등록하여 사용한다.
- 등록 방법: @Component, @Service, @Repository, @Controller 등의 어노테이션을 사용하거나 XML 설정 파일에서 <bean> 요소를 이용하여 등록할 수 있다.
- 주의점
- 싱글톤을 멀티스레드 환경에서 사용할 때는 상태를 가지지 않는 무상태(Stateless)객체로 설계되어야만 멀티스레드 환경에서 안전하게 사용 가능하다.
- 상태를 가진 객체로 설계 해야 한다면, 동기화(synchronization)을 사용하여 스레드 안정성을 보장해야 한다.
- 빈은 기본적으로 싱글톤으로 관리되지만, 필요에 따라 프로토타입(scope="prototype")으로 설정하여 매번 새로운 인스턴스를 생성할 수도 있다.
- 애플리케이션에서 해당 빈은 하나의 인스턴스만 존재하며, 모든 요청에 대해 동일한 객체를 반환한다.
- 메모리 절약과 객체 재사용이 가능하고, 애플리케이션의 성능 향상에도 기여한다.
⚠️빈으로 등록하지 않고 사용하는 것과의 차이를 알아보고, 어노테이션을 자세히 알아보자!
빈으로 등록하지 않고 사용하는 것과의 차이
빈으로 등록하지 않은 경우
- 객체 생성 및 관리가 수동적이며, 의존성 주입을 활용할 수 없고, 객체 간 결합도가 높아진다.
- 생명주기 관리와 같은 스프링의 장점을 활용할 수 없다.
빈으로 등록하는 경우
- 스프링 IoC 컨테이너가 객체의 생명주기와 의존성을 관리하며, DI 및 AOP와 같은 기능을 활용할 수 있다.
- 결합도가 낮아지고, 유지보수성이 향상된다.
@Component
- 기본적인 빈 등록 어노테이션이다. 이 어노테이션을 클래스에 추가하면, 해당 클래스의 객체는 스프링 IoC 컨테이너에 자동으로 등록 된다.
- @Component는 스프링의 일반적인 빈 등록에 사용되며, 특별한 역할이 없는 클래스에 사용된다.
@Service
- 서비스 레이어에서 사용되는 클래스에 붙이는 어노테이션이다.
- @Service는 @Component의 특별한 형태로, 서비스 계층의 비즈니스 로직을 처리하는 클래스를 빈으로 등록할 때 사용된다.
- 기능적으로 @Component와 동일하지만, 클래스의 역할을 명확하게 구분하려는 목적이 있다.
@Repository
- DAO(Data Access Object) 레이어에서 사용되는 클래스에 붙이는 어노테이션이다.
- @Repository는 @Component의 특별한 형태로, 데이터베이스와의 상호작용을 담당하는 클래스에 사용된다.
- 이 어노테이션은 @Component 처럼 빈으로 등록되지만, 예외 처리와 관련된 특별한 기능이 제공된다.
- 예: 데이터베이스 관련 예외를 스프링의 DataAccessException으로 변환하여 처리할 수 있다.
@Controller
- 웹 계층에서 사용되는 클래스에 붙이는 어노테이션이다.
- @Controller는 주로 스프링 MVC의 컨트롤러 역할을 하며, HTTP 요청을 받아 처리하고, 응답을 반환한다.
- 만약 RESTful API를 작성하는 경우에는 @RestController를 사용하여 응답을 자동으로 JSON으로 변환할 수 있다.
빈팩토리(BeanFactory)
스프링의 빈팩토리(BeanFactory)는 IoC의 기본 기능을 담당하는 핵심 컨테이너 이다. 주로 빈의 생성, 조회, 관리를 담당하며, 스프링 설정 파일(XML 등)에서 빈을 정의하고 스프링이 그 빈들을 관리하게 한다.
- 개념: 스프링의 IoC 컨테이너의 핵심 역할을 담당하는 인터페이스이다. 빈의 생성, 조회, 관계 설정 등의 기본적인 기능을 제공한다.
- 구현체: XmlBeanFactory가 대표적으로 사용되며, XML 설정 파일을 기반으로 빈을 관리한다. 최근 스프링 버전에서는 더 많은 기능을 제공하는 DefaultListableBeanFactory가 주로 사용된다.
애플리케이션 컨텍스트(Application Context)
애플리케이션 전반에 걸쳐 모든 구성요소의 제어 작업을 담당하는 IoC 엔진이라는 의미가 부각된다. IoC 컨테이너라 하기도 하고 스프링 컨테이너 라고 부르기도 하고 빈 팩토리라고 부를 수 도 있단다. 이 컨텍스트는 스프링 애플리케이션의 전반적인 구성 요소를 제어하고, 스프링에서 제공하는 여러 서비스(트랜잭션, AOP, 이벤트 발행 등)를 지원한다.
- 개념: 빈팩토리를 확장한 IoC 컨테이너로, 모든 스프링 애플리케이션에서 사용되는 주요 컨테이너 이다.
- 기능: 빈팩토리의 모든 기능을 포함하고, 트랜잭션 관리, 이벤트 발행, AOP 등의 추가 기능을 제공한다.
- 구현체: ClassPathXmlApplicationContect, AnnotationConfigApplicationContext 등이 있고, XML 설정 파일이나 자바 설정 클래스를 기반으로 빈을 로드하고 관리한다.
빈팩토리라고 부를 때는 빈의 생성과 제어의 관점에서 이야기 하는것이고, 애플리케이션 컨텍스트라고 할 때는 스프링에서 제공하는 애플리케이션 지원 기능을 모두 포함해서 이야기 하는 것 이라고 보면된다. 싱글톤을 저장하고 관리하는 싱글톤 레지스트리 이기도 하다.
싱글톤 레지스트리(Singleton Registry)
자바의 기본적인 싱글톤 패턴은 여러 단점이 있는데, 스프링에서는 이를 개선해서 싱글톤 레지스트리를 통해 싱글톤 객체를 관리한다.
- 싱글톤 레지스트리는 스프링 컨테이너 내에서 싱글톤 객체의 생성, 관리, 공급을 담당하는 관리 체계이다.
- 스프링 컨테이너는 애플리케이션 내에서 싱글톤 객체를 효율적으로 관리하고 제공할 수 있다.
@Configuraion
빈 팩토리를 위한 객체 설정을 담당하는 클래스로 인식될 수 있도록 하는 어노테이션이다. 이 어노테이션을 사용하면 해당 클래스가 빈 설정 정보를 관리하는 설정 클래스로 동작 한다.
- 기능
- @Configuration을 사용하면, 해당 클래스가 스프링의 설정 클래스임을 스프링이 인식하고 이 클래스를 빈 설정에 사용한다.
- 이클래스 내에서는 @Bean 어노테이션을 사용해 스프링 IoC 컨테이너에 관리할 빈을 등록할 수 있다.
- 동작 방식
- @Configuration이 붙은 클래스는 빈 설정 클래스로 간주되고, 이 클래스에서 정의한 메소드들은 빈을 정의하고 설정하는 역할을 한다.
- @Configutaion을 사용할 경우, 클래스 내부에서 정의된 메소드들은 빈팩토리(Bean Factory)의 역할을 하여 객체를 스프링 컨테이너에 등록한다.
- 내부의 메소드들에 @Bean 어노테이션을 사용하면 해당 메소드가 빈으로 등록되고, 의존성 주입이 가능해진다.
- 싱글톤 보장
- @Configutaion이 적용된 클래스는 싱글톤 레지스트리를 활용하여 빈을 생성한다. 이 클래스에서 정의한 메소드들은 스프링 컨테이너에 의해 관리되고, 싱글톤으로 등록된다.
- @Configutaion을 붙인 클래스 내에서 메소드를 호출하는 것만으로 빈을 여러번 생성하지 않고 싱글톤 객체를 재사용하도록 보장한다.
IoC 컨테이너
IoC 컨테이너는 스프링이 빈을 관리하는 방식으로, 빈의 생성, 관계 설정, 생명주기 관리를 담당하는 핵심 컨테이너이다.
애플리케이션 컨텍스트(ApplicationContext)나 빈팩토리(BeanFactory)는 IoC 컨테이너의 구현체이다. 이둘 모두 컨테이너 또는 IoC 컨테이너라고 불리고, 빈을 관리하는 핵심 기능을 제공한다.
- 기능
- IoC 컨테이너는 객체(빈)를 생성하고, 객체 간의 의존성 주입을 관리한다.
- 빈은 스프링 IoC 컨테이너가 생성한 객체로, 객체의 생명주기와 관리를 스프링이 대신해주므로, 개발자는 객체를 수동으로 생성하고 관리할 필요가 없다.
- 동작 방식
- 스프링 IoC 컨테이너는 빈 팩토리(BeanFactory) 또는 애플리케이션 컨텍스트(ApplicationContext)로 구현된다.
- 스프링은 빈을 자동으로 생성하고, 의존성을 주입하며, 필요에 따라 스코프(싱글톤, 프로토타입 등)를 설정하여 객체를 관리한다.
동일성(identity)와 동등성(equality)
- 동일성(identity): 두 객체가 같은 객체인지를 비교할 때 사용된다. 자바에서는 == 연산자를 사용하여 객체의 동일성을 비교한다.
- 동등성(equality): 두 객체의 값이 동일한지를 비교할 때 사용된다. 자바에서는 equals() 메서드를 사용하여 객체의 동등성을 비교 한다.
스프링의 빈 스코프
- 개념
- 스프링이 관리하는 오브젝트, 즉 빈이 생성되고, 존재하고, 적용되는 범위를 빈의 스코프 라고 한다.
- 스프링 빈의 기본 스코프는 싱글톤이다.
- 프로토타입스코프
- 컨테이너에 빈을 요청할 때마다 매번 새로운 오브젝트를 만들어 준다.
제어의 역전(IoC)과 의존관계 주입
- 제어의 역전
- IoC(Inversion of Control)는 객체의 생성과 의존 관계 설정을 프레임워크나 외부 컨테이너가 담당하도록 하여, 객체가 직접 관리하지 않도록 하는 설계 패턴이다.
- 객체가 자신의 생명주기를 관리하는 것이 아니라 스프링 컨테이너가 이를 대신 수행한다.
- 스프링의 IoC 컨테이너는 객체를 생성하고, 객체 간의 관계를 설정하며, 객체를 관리하는 역할을 한다.
- 의존관계 주입(DI)
- DI(Dependency Injection)는 IoC의 구현 방식 중 하나로, 객체가 자신이 사용할 의존 객체를 외부에서 주입받는 방식이다.
- DI의 핵심은 객체가 의존성을 직접 생성하거나 관리하지 않고, 외부에서 주입받는 것 이다. 이것으로 객체 간의 결합도를 낮추고, 유연한 시스템 설계를 가능하게 한다.
- 의존 관계 검색과 주입
- 의존 관계 검색은 객체가 직접 의존하는 객체를 검색하여 사용하는 방식이다. 이는 DI 방식과 차이가 있다. DI는 외부에서 주입받는 방식이고, 의존 관계 검색은 객체가 스스로 의존성을 찾아서 사용하는 방식이다.
- 의존 관계 주입은 외부에서 객체가 의존하는 객체를 제공하고, 이를 통해 객체 간의 의존성을 해결한다.
- 메소드를 이용한 의존관계 주입
- Setter 메소드를 이용한 주입
- Setter 메소드는 객체의 속성값을 설정하기 위해 사용된다. DI에서 이 메소드를 활용해서 외부에서 객체를 주입받을 수 있다.
- Setter 메소드는 객체가 외부에서 전달받은 값을 내부 속성에 설정하여, 객체가 이를 사용할 수 있도록 한다.
- 일반 메소드를 이용한 주입
- 일반 메소드를 이용한 DI는 여러개의 파라미터를 갖는 메소드를 이용하여 의존성을 주입하는 방식이다. 여러 의존성을 하나의 메소드에서 처리할 수 있어 유연하게 의존성을 관리할 수 있다.
- Setter 메소드를 이용한 주입
@Component
public class OrderService {
private UserService userService;
private ProductService productService;
// 일반 메소드를 통한 의존성 주입
@Autowired
public void setupServices(UserService userService, ProductService productService) {
this.userService = userService;
this.productService = productService;
}
public void processOrder(String userId, String productId) {
// 주입된 의존성을 활용
String userInfo = userService.getUserDetails(userId);
String productInfo = productService.getProductDetails(productId);
System.out.println("Processing order for user: " + userInfo + " with product: " + productInfo);
}
}
Setter vs 일반 메소드
특징 | Setter 메소드 DI | 일반 메소드 DI |
주입 대상 | 한 번에 하나의 의존성 주입 | 여러 의존성을 한 메소드에서 주입 |
사용 목적 | 간단한 필드 값 설정 | 여러 의존성을 처리하거나 추가 로직 포함 |
주입 방식 | set~()메소드 | 임의의 메소드 사용 |
유연성 | 비교적 제한적 | 더 복잡한 로직을 포함 가능 |
하 1장부터 두손 두발 다들었다 진짜 1장인데 엄청 내용이 많아.........
** 그냥 하루하루 개인 공부한 것을 끄적 거리는 공간입니다.
이곳 저곳에서 구글링한 것과 강의 들은 내용이 정리가 되었습니다.
그림들은 그림밑에 출처표시를 해놓았습니다.
문제가 될시 말씀해주시면 해당 부분은 삭제 하도록하겠습니다. **
'public void static main > Book' 카테고리의 다른 글
[토비의스프링] 2장-테스트 (1) | 2025.01.29 |
---|---|
[Elasticsearch Bible] 1장 소개 ~ 2장 동작과 구조 (1) | 2025.01.29 |
[대규모 시스템 설계 기초] 3장, 4장 (1) | 2025.01.08 |
[대규모 시스템 설계 기초] 1장, 2장 (1) | 2025.01.06 |
[JVM 밑바닥] 7장 클래스 로딩 메커니즘 (1) | 2024.11.17 |
댓글