[Spring] 스프링 각종 용어 및 개념 정리,,

JAVA\Spring

by 박집실 2022. 11. 18. 00:31

# 자바빈

- 자바빈(JavaBean) 은 원래 비주얼 툴에서 조작 가능한 컴포넌트였지만 이제는 인기를 잃어서 해당 컴포넌트의 스타일의 두 가지 관례에 따라서 만들어진 오브젝트를 가르킴. 간단히 빈이라 말하기도 함

1. 디폴트 생성자: 자바빈은 파라미터(매개변수)가 없는 생성자를 가지고 있어야함. 툴이나 프레임워크에서 리플렉션을 활용해 객체를 생성하기 때문.

2. 프로퍼티: 자바빈이 노출하는 이름을 가진 속성은 프로퍼티.

-set으로 시작하는 수정자 메소드는 수정 기능할시

-get으로 시작하는 수정자 메소드는 조회 기능할시

# 디자인 패턴

[Spring] 디자인 패턴 (tistory.com)

# 제어의 역전(IoC)

- 프로그램의 제어 흐름 구조가 뒤바뀌는 것.

[Spring] 제어의 역전(IoC)에 관한 고찰 (tistory.com)

# 팩토리(설계도, 설정정보) ex) XML 등등..

- 객체의 생성 방법 결정 후 반환을 하는 역할을 수행하는 오브젝트(위 팩토리 - 메소드 패턴에서 팩토리와는 다른 개념)

# 빈(스프링 빈)

- 스프링에서 스프링이 제어권을 가지고 직접 만들고 관계를 부여하는 오브젝트. 즉쓴, 자바빈에서 말하는 빈과 비슷한 오브젝트 단위의 애플리케이션 컴포넌트이다. 스프링 빈은 스프링 컨테이너가 생성과 관계 설정, 사용 등을 제어해주는 제어의 역전이 적용된 오브젝트

# 빈팩토리 / 애플리케이션 컨텍스트(싱글톤 레지스트리)

- 빈 팩토리: 빈의 생성과 관계설정 같은 제어를 담당하는 IoC 오브젝트

- 애플리케이션 컨텍스트: 별도의 설정정보를 참고해서 애플리케이션 전반에 걸쳐 모든 구성요소의 제어작업을 담당하는 일종의 IoC엔진. 즉, IoC 방식으로 만들어진 일종의 빈 팩토리.

이를 정리하자면 기본적으로 애플리케이션 컨텍스트가 빈 팩토리보다 좀 더 포괄적인 개념을 가지고 있지만 본질적으로는 두 단어 다 동일한 개념을 가르킨다. 빈 팩토리는 빈을 생성하고 관계를 설정하는 IoC의 기본 기능에 초점을 맞춘 것이고 애플리케이션 컨텍스트는 애플레키이션 전반에 걸쳐 제어 작업을 총괄하는 IoC엔진을 뜻 함.

# 서블릿

- 서블릿은 서버 측에서 웹 요청과 응답의 흐름을 간단한 메서드 호출만으로도 체계적으로 다룰 수 있게 해줘 자바 기반 서버의 성능을 향상 시키기 위한 자바 기반 웹 애플리케이션 프로그래밍 기술

[Web] 서블릿(Servlet)이란 무엇인가? 서블릿 총정리 (tistory.com)

[Web] 서블릿(Servlet)이란 무엇인가? 서블릿 총정리

서블릿(Servlet)이란? 서블릿이란 Dynamic Web Page를 만들 때 사용되는 자바 기반의 웹 애플리케이션 프로그래밍 기술입니다. 웹을 만들때는 다양한 요청(Request)과 응답(Response)이 있기 마련이고 이 요

coding-factory.tistory.com

자바 서블릿 - 위키백과, 우리 모두의 백과사전 (wikipedia.org)

자바 서블릿 - 위키백과, 우리 모두의 백과사전

위키백과, 우리 모두의 백과사전. 서블릿은 여기로 연결됩니다. 다른 뜻에 대해서는 서블렛 문서를 참고하십시오. 자바 서블릿(Java Servlet)은 자바를 사용하여 웹페이지를 동적으로 생성하는 서

ko.wikipedia.org

# 싱글톤

- 한 클래스의 인스턴스를 딱 한개만 생성 후 전역적으로 접근해 사용하게 하는 것

[Spring] 싱글톤? (tistory.com)

# 빈의 스코프

- 빈이 생성되고 , 존재하고, 적용되는 범위. 기본적으로 설정된 값은 싱글톤

# 의존관계 주입(DI)

- Dependency Injection, 또는 의존(종속) 오브젝트 주입이라고도 부르는데 이는 DI가 일어나는 방법에 초점을 맞춘 것. 엄밀히 말해서는 객체 자체가 직접 다른 객체에 들어가는 것이 아니라 객체의 주소값이 전달되는 것이다. DI는 주소값을 외부로 부터 제공받고 이를 통해 다른 객체들과 다이나믹한 의존관계가 설정되는 것. 이를 위해서는 인터페이스 형태의 매개변수로 이루어져야함. 다른 용어로 '의존관계설정'이라 부르기도 함. DI를 원하는 오브젝트는 먼저 자기 자신이 컨테이너가 관리하는 빈이 되어야한다.(컨테이너가 오브젝트를 주입해주려면 주입당하는 오브젝트(A라 칭함)에 대한 생성과 초기화 권한을 가지고 있어야하고 이를 위해선 A는 IoC방식으로 컨테이너에서 생성되는 오브젝트, 즉 빈이어야 함. 밑 링크 참조)

[Spring Boot] Bean과 의존성 주입(Dependency Injection) (tistory.com)

[Spring Boot] Bean과 의존성 주입(Dependency Injection)

Bean에 대해서 설명하기에 앞서 Spring에서 등장하는 IoC 컨테이너에 대해서 이야기 해본다. IoC는 Inversion Of Control Container의 약자로 기존의 모든 제어를 클라이언트의 코드가 가지도록 구현하던 것

ch4njun.tistory.com

의존관계 주입 아래 3가지를 만족해야함.
1. 클래스 모델이나 코드에는 런타임 시점의 의존관계가 드러나지 않는다. 그러기 위해서는 인터페이스에만 의존하고 있어야한다.

2. 런타임 시점의 의존관계는 컨테이너나 팩토리 같은 제3의 존재가 결정

3. 의존관계는 사용할 오브젝트에 대한 레퍼런스를 외부에서 제공해줌으로써 만들어진다.

# 의존 오브젝트

- 프로그램이 시작되고 애플리케이션 컨텍스트가 만들어지고 나서 런타임시에 의존관계를 맺는 대상. 실제 사용대상인 오브젝트. 즉 의존관계 주입은 이렇게 구체적인 의존 오브젝트와 그것을 사용할 주체(클라이언트) 를 런타임 시에 연결해주는 작업

# DI 컨테이너 = DI 프레임워크 = IoC 컨테이너 = IoC/DI 컨테이너 = 스프링

- 설계도 즉, 팩토리는 보통 두 오브젝트 사이의 런타임 의존관계를 설정해주는 의존관계 주입 작업을 주도하는 존재. 동시에 IoC방식으로 오브젝트의 생성과 초기화, 제공 등의 작업을 수행하는 컨테이너. 따라서 DI를 담당하는 컨테이너라고 볼 수 있으며 이를 DI 컨테이너라고 함.

다시 정리하자면 DI는 자신이 사용할 오브젝트에 대한 선택과 생성 제어권을 외부로 넘기고 자신은 수동적으로 주입받은 오브젝트를 사용한다는 점에서 IoC의 개념에 잘 들어맞는다. 스프링의 IoC는 주로 의존관계 주입에 초점이 맞춰져있다.이로 인해 스프링은 DI 컨테이너 = DI 프레임워크 = IoC 컨테이너 = IoC/DI 컨테이너 등 다양한 명칭으로 불린다.

# 의존관계검색 ( getbean(); )

- 코드에서 구체적인 클래스에 의존하지 않고 런타임 시에 의존관계를 설정하는 점에서 DI 와 비슷하지만 주입 받는 방식이 아니라 스스로 검색을 해서 잦는다. 하지만 자신이 어떤 클래스의 오브젝트를 이용할지는 결정하지는 않음. 이것은 IoC의 개념에 위배되기 때문.

즉쓴, 의존관계검색은 런타임 시 의존관계를 맺은 오브젝트를 결정하는 것과 오브젝트의 생성 작업은 외부 컨테이너에게 IoC로 맡기지만, 이를 가져올 때는 메소드나 생성자를 통한 주입 대신 스스로 컨테이너에게 요청하는 방법을 사용.

검색하는 오브젝트는 자신이 스프링의 오브젝트일 필요가 없다. (new UserDao() 등으로 사용가능. getbean()을 이용하여 검색 작업을 동작시키는 코드 내에서 직접 찾아버리기 때문)

=> DI 쪽이 코드가 훨씬 단순하고 깔끔하다. 무엇보다 의존관계검색은 코드안에 오브젝트 팩토리 클래스나 스프링 API가 들어나기 때문에 성격이 다른 오브젝트에 의존하게 되는 것 즉, 해당 클래스에서 하고자하는 작업과 이질적인 역할을 하는 다른 API 등이 코드상에 들어난다. 그래서 보통의 상황에서는 의존관계검색보다는 DI를 쓴다. 한편 스타팅 포인트에서는 즉쓴, main()이나 서버의 서블릿에서는 시작할 때 무조건 쓰여야 하니 결론적으로 한 번 이상은 쓰여야 함.(스태틱 메소드인 main()은 DI를 이용해서 오브젝트를 주입받을 방법이 없기 때문)

# 높은 응집도, 낮은 결집도 - 관심사의 분리(SoC)

- 관련이 높은 코드와 기능들은 하나의 클래스 내로 관련이 적은 코드와 기능들은 서로 다른 클래스로 독립시켜 분리하여 관리.

# XML - DTD 와 스키마

- XML은 미리 정해진 구조를 따라서 작성되었는지 검사할 수 있다. XML 구조를 정의하는 방법에는 DTD 와 스키마가 있다.

DTD:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

스키마:

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="http://www.springframework.org/schema/beans
                  http://www.springframework.org/schema/beans/spring-beans-3.0.xsd">

스프링은 DI를 위한 기본 태그인 <beans>, <bean> 외에도 다양하게 활용가능한 태그들을 활용할 수 있는 방법들이 있다. 이 태그들은 스키마 파일에 정의되어 있고 독립적인 네임스페이스를 사용해야함. 이를 위해서는 스키마를 사용해야한다. <beans> 태그를 기본 네임스페이스로 하는 스키마 선언은 위 코드와 같다. 다음과 같은 이유로 스키마를 더 많이 쓰이며 또한 더욱 바람직하다.

# 컨텍스트 <-> 클라이언트

- 컨텍스트는 스프링이 사용되는 곳 즉 ,서버 및 이와 비슷한 역할을 하는 장치에 위치 혹은 그 자체를 지칭

ex) 아마도 애플리케이션 컨텍스트??

'JAVA\Spring' 카테고리의 다른 글

[Spring] 제어의 역전(IoC)에 관한 고찰 (0)	2022.11.22
[Spring] 디자인 패턴 및 객체지향을 위한 코딩습관 (0)	2022.11.21
[JAVA] 임의로 Socketexception 발생시키기 (0)	2022.11.17
[JAVA] 자바 패키지 컴파일 할 때 안될 때 (0)	2022.11.14
[JAVA] 상호통신에서 InputStream/OutputStream 설정 (0)	2022.10.11