Spring 프레임워크 개요

 

✔️ 프레임 워크의 개요

 

1. SpringBoot

2. Spring기반으로한 자체 프레임워크 <<< 보통 요즘 많이 쓰고 있는 방식

 

프레임 워크 == 골격

-> 예시 ) 리모콘 : 리모콘을 만드는 메뉴얼 같은것을 정한다. 그러면 다음 개발자가 오더라도 메뉴 버튼을 어떻게 만드는지 메뉴얼이 있을 것이다.

 

장점

 

1. 유지보수 용이

2. 개발자들의 기준이 정해짐 → 개발 시간단축, 비용절감

3. 개발자들의 가이드 라인으로 이정도는 해야된다라는 기준이 생김→ 개발자의 역량이 획일화 & 실력 상향 평준화

4. 코드 재사용이 용이 (역량이 획일화 되기 때문)

 

 

✔️ Spring 프레임 워크

 

: IoC 와 AOP를 지원하는 경량의 프레임워크 ( POJO를 의미 ) == 낮은 결합도, 높은 응집도 == 유지보수 용이

POJO

↕

not POJO(Servlet , 리스너 , 필터) 링크 참조 ! (배운 내용들 )

FrontController

java 에서 mvc를 적용한것 처럼, jsp 에서 프레임 워크 구조를 적용할 예정! -> Controller 파트를 수...

blog.naver.com

리스너 ( jsp 크롤링 )

[리스너] : 특수한 형태의 서블릿 : 특정시간에 기능을 추가함 (서블릿이 동작되었을때 , 서버가 시작할때 ...

blog.naver.com

필터 (.java 클래스)

필터 하면 어떤게 떠오를까요 ? 카메라 어플 스노우 라는 화면 필터가 있고, 우리가 물을 마시는 정수기에 ...

blog.naver.com

 

POJO 를 기반으로 국비 과정 중 이미 경량으로 사용중이었다.

우리는 이미 JSP 팀 프로젝트에서 경량으로 Servlet을 FrontController 한개만 생성하여 사용했다 . API,비동기처리 기능등을 구현할때에 Servlet을 추가로 사용했다.

이 내용들을 이제 사용하더라도 pojo로 사용해보는것이 Spring 목표이다 !

 

 

 

✔️ IoC ( Inversion of Control ) 에 대해 알아보자

 

그래서 IoC가 뭐야 ?

제어의 역행, 개발자가 new (객체화, 인스턴스화)를 제어 하지 않는다.

프레임워크에게 제어권을 넘겨주는것.

 

★ 코드에 new가 작성되어 있으면 유지보수 불리하다.

new 를 작성될때 마다 결합도가 높아지므로 유지보수 불리

 

그래서 , 우리는 결합도가 높은 코드를 결합도를 낮추고 응집도를 높이도록 해결해야 한다.

 

★★★ 해결 방법

 

해결01 - 다형성 활용하기

개발자들의 설계 단계라고 생각 - 정해지는 약속,메뉴얼,규칙 등이 없으면 각자의 스타일대로 만든다. 그래서 약간의 틀을 정해주는것 .

 

 

 

해결 02 - sw 개발 디자인 패턴 ( MVC, Factory, singleton ,,,,)

★ Factory 패턴 이란?

 

→ 객체를 생성하는 코드를 캡슐화 하여 (= new 와 관련된 코드를 은닉하여)

결합도는 떨어뜨리고 사용자에게 뭐 필요한지 물어봄

필요한애 이름을 받아서 사용자로부터 필요한 객체의 이름을 받아 객체자체를 반환하는 로직

 

코드를 단 한글자도 변경하지 않아도 결과 (화면)가 달라진다 !!!

재 컴파일을 할 필요가 없기 때문에

---

FrontController에서 봤었던 구조 !

output 이 Object 인 이유 최상위 객체라서 어떤 것이든 반환 되도록

 

RUN - Run Configurations 클릭 - Arguments 에 글자 입력 !

그러면 아이폰이라는 값이 들어가면서 new IPhone() 객체 실행

---

설정파일 == .xml ( 설정은 보통 xml )

1. web.xml - 톰캣관련설정 사항과 관련

2. pom.xml - Spring 관련설정파일 ( .jar 파일들에 대한 관리 설정 관련 )

3. applicationContext.xml - Spring 관련설정파일 (Spring 컨테이너 관련 설정 파일 )

 

 

( 여기서 잠깐 TMI )

<!-- 객체를 생성해줘 -->

<!-- new 코드를 개발자 대신 해줘 -->

이처럼 xml 안에서 주석 권장 하지 않는다.

 

beans 안에 bean 있다.

 

<bean> 이라는 태그로 new를 개발자대신 해준다 ★★★★

<bean class="test.IPhone" id="apple" />

→ 원래 객체화 였던것 IPhone apple = new IPhone();

 

<bean class="test.GalaxyPhone" id="galaxy"/>

GalaxyPhone galaxy = new GalaxyPhone (원래는 이것, 객체화를 의미)

: 디폴트로 pre-loading 방식을 사용함(즉시로딩방식)

 

설정을하면 lazy-init 방식을 할수도있음(지연로딩방식)

 

 

 

코드에 new가 없을수록 코드에 결합도가 낮아져서 좋다.

Factory 패턴을 써서 new 를 없애면 유지보수 용이

앞으로는 Factory패턴 한테 맡겨 나갈 거다 .

 

 

객체를 1개만 메모리에 생성하고 해당 객체를 재사용함

== 싱글톤(singleton) 패턴 방식

: 디폴트로 scope="singleton"

---

★ 컨테이너란 무엇인가 ?

== 객체를 생성하는 주체

== 개발자가 설정(.xml)만 해주면 new는 스스로 관리함

== 객체 생성 및 관리를 스스로 처리함

== "컨테이너"는 설정 파일을 보고 처리하는 애이기 때문에

설정을 꼭 해줘야 하므로 + .xml 이 작성될 수 밖에 없다.

 

• new (객체화) 를 할 수 있는 2가지 방법

1) .xml 에선 <bean> -> 자바의 파일을 변경할 일이 없기 때문에 재컴파일이 줄어든다. 근데 너무 많이 사용시 가독성이 떨어진다.

2) @ -> 자바 구조 파악을 위해 주로 사용한다. .xml을 아예 사용안하는 것이 아님

 

@Component == <bean>

@Autowired == <property>

.

.

.

 

 

여기서 잠깐 !

우리는 이미 컨테이너를 사용하고 있었다.

서블릿 파일 에서의 @WebServlet() 얘가 유사 new 이다.

이걸 해주면 new를 해주라고 약속했는데 web.xml이랑 약속을 했다. web.xml은 톰캣 관련

톰캣 == 서블릿 컨테이너

== 서블릿 new를 해주는 주체

== 서블릿을 new해주는 주체

 

doAction이 되고 있다 ?-> 그러면 객체가 있다-> 그러면 누가 new Frontcontroller 를 하고 있는

Frontcontroller 는 서블릿 파일 이었다.

1. 톰캣은 서버와 동시에 "서블릿 컨테이너" 를 해줬다. (서버 뿐 아니라 톰캣의 역할 )

2. @WebServlet() 이 있다면 new 해줌

3. new 뿐만아니라 생성시점, 호출 시점등도 관리 가능

 

리스너를 보면 알 수 있다. 서블릿이 시작할때 하라구

필터로 호출시점을 관리 할 수 있다.

 

Q. ) doAction()이 되고 있었네 ?

객체가 있었다는 건데 ?

누가 객체화 (new) 를 해줬을까

=> 서블릿 컨테이너 (톰캣)

 

그래서,

<bean> 태그로 pojo를 만들면 스프링 컨테이너

@Servlet -> 서블릿을 만들면 서블릿 컨테이너 (톰캣)

---

 

<bean>태그가 GalaxyPhone에서 객체화 해준 변수 이름이 "galaxy" 이다.

그 변수를 request처럼 요청으로 불러와 타입을 변환 하여 맞춰 준다. 이로서

phone은 GalaxyPhone 클래스의 메서드 기능들을 수행하게 된다.