Spring Framework 기초 #Day1

Framework : 프로그래밍을 하기 위한 어떠한 틀이나 구조를 제공

• 장점
  • 효율적으로 코드를 작성(개발자가 핵심로직에 개발하는 것에 집중)
  • 정해진 규약이 있어 유지보수, 재사용, 확장 등이 용이함
• 단점
  • 사용할 framework에 대한 학습이 필요
  • 자유롭고 유연한 개발이 어려움
• Libarary와의 차이 : Library는 애플리케이션 흐름의 주도권이 개발자에게 있는 반면, Framework은 애플리케이션 흐름의 주도권이 개발자가 아닌 Framework에 있다.

---

서블릿 구성(요약)

WAS 내에서 동작하며, (WAS 없이 웹애플리케이션=동적 웹서비스 는 불가)

1. 웹컨테이너(web.xml) : 외부 클라이언트가 서버로 진입할 때 웹 컨테이너가 받아서 매니지먼트 해줌(스레드 생성하고 서블릿을 실행시켜줌)(스레드 생성하고 서블릿과 연동)

2. 스레드 : req만큼 생성

--- WAS 영역 -----

3. Dispahcher Sevlet (Spring에만 존재 : Front Controller Pattern) : 스레드당 서블릿이 관연되는 복잡도를 낮춤 (스레드와 상관없음)

4. 싱글톤 Sevlet (Spring - Controller라고 명명)

--- Servlet 영역 -------

 

---

웹 서비스의 발전

As-is : 정적 (html) req → 웹서버(정적)

To-be : 동적 (프로그램 = 애플리케이션)

문제. 각 언어(C, Perl, PHP등)들이 동적으로 웹페이지를 동적으로 제공하고자 각각 개발함 → 개발과 유지보수가 어려워짐

⇒ CGI(Common GW Interface) 등장 : req → 웹 서버(정적) ↔ CGI구현체

문제. 여러개 요청에 대해 프로세스 단위로 CGI 구현체를 동작시킴 (서버에서는 부담이 많이 됨) → 많은 사용자를 감당하기 어려움

⇒ 프로세스 단위가 스레드 단위로 변경됨(프로세스 간에는 메모리(코드, 데이터, 힙) 공유 불가(프로세스 내의 스레드 간에는 공유 가능))

문제. 어느정도 해결되었으나 CGI 구현체가 요청만큼 생성되어야 함 → 여전히 많은 사용자를 받을 수 없음

⇒ 싱글톤 : 객체가 하나 만들어지면, 하나의 인스턴스를 돌려씀. req → thread → 싱글톤 CGI 구현체로 처리

문제. 싱글톤들의 객체를 관리하는 대기소가 필요함 ⇒ 컨테이너 : req → 컨테이너 → thread → 싱글톤 CGI 구현체로 처리

• 컨테이너가 중재해줌 : 스레드 생성여부, CGI 실행 (매번 생성이 아니고 실행임)

⇒ 모두 합쳐서 서블릿Servlet (자바로 작성되어 있음) → 자바가 웹을 장악하기 시작함 (2000년도 초반)

 

서블릿의 발전

문제 : 복잡하다(간단한 내용에 대해 자바에서 html을 만들어서 return)

동적으로 처리해야 하는부분만 서블릿에서 처리하고, 나머지는 정적인 곳에서 받아서 처리해줘 (front/back)
→ 하이브리드, jsp : <% 자바 문법 → 가독성이 너무 떨어짐 ⇒ JSTL(자바를 html처럼 쓰도록함)

문제 : 서블릿에 다 넣어놓다보니 유지보수가 어려움(화면은 분리했지만, DB 등)

→ 개발패턴이 생김 MVC(M : 서블릿, V : 페이지 영역 담당, C : 컨트롤러)(06년쯤)

문제 : MVC 패턴을 정의하는게 개발자마다 다름

→ 웹 MVC를 표준화하기 시작함(표준화는 아니지만..) → Spring Framework

스프링 프레임워크 : 웹 MVC를 (표준화하여) 일관되게 제공

• 서블릿을 조금 더 정제해서 신뢰할 수 있도록 표준화하여 도구화함(누구나 동일 품질로 가져다 쓸 수 있도록하여 로직에만 집중하게끔 제공)
• 웹 MVC를 신뢰할 수 있게 위임(위임하려면 표준 프로세스가 상대방과 동일하게 인지되어 있어야 함)
• 서블릿은 핵심개념이지만 스프링은 잘 구성해둔 도구임

정적인 웹 서비스 → CGI(최초의 동적) → 서블릿(Servlet) → JSP 등장→ MVC 개발 패턴(패턴은 있는데 각자함) → 대표적인 웹 MVC(Spring 등장)

 

서블릿의 단점 (Spring Framework 개선 영역)

• (일반 서블릿 구조) 각기 다른 요청이 n개 이면 n개의 싱글톤이 생성됨(스레드 방식을 통해)
• (일반 서블릿 구조) req→ 웹컨테이너(설정파일 web.xml) → thread → Servlet(싱글톤 구성)

⇒ 서블릿을 좀 더 큰 구성으로 변경 (스레드와 서블릿 사이에서 중재)

⇒ front controller pattern에 의해 고안되어 서블릿 앞에 “Dispatcher Servlet” 이라는 관리하는 서블릿이 추가됨

• WAS에서 구동하려면 기존 싱글톤 서블릿을 → web.xml 설정파일에 등록되어야 함(n개)
• dispatchservelet을 만들면 WAS(여기서는 웹컨테이너)는 디스패처만 바라보면(등록되면) 됨
• 디스패처서블릿이 핸들링해서 싱글톤 서블릿 들한테 전달함 >> 스레드가 1개만 생성되면 됨!

req → 웹컨테이너 → 스레드 → 디스패처 서블릿(1개) → 각 서블릿(Controller)

디스패처 보조: 연결작업은 디스패처가 함(처리요청)

1. Hadler Mapping : 어떤 컨트롤러에게 전달해줘야 하는지 찾는 역할
2. View 담당 : 컨트롤러가 처리한 결과를 화면에 뿌려줌

 

 

참고. 싱글톤 패턴

생성자가 여러 차례 호출되더라도 실제로 생성되는 객체는 하나이고 최초 생성 이후에 호출된 생성자는 최초의 생성자가 생성한 객체를 리턴

→ "해당 객체의 인스턴스가 한 개만 존재하여야 하는지?"의 여부와 "사용을 하였을 때의 동시성 문제가 발생하지 않는지"를 체크하여 사용할 것

멀티스레드의 경우 여러개의 인스턴스가 생성되거나 변수 값 일관성이 실패하는 등의 문제가 있기 때문에 아래와 같이 static innner class 사용하는 방법이 일반적이다.

public class Something {
    private Something() {
    }
 
    private static class LazyHolder {
        public static final Something INSTANCE = new Something();
    }
 
    public static Something getInstance() {
        return LazyHolder.INSTANCE;
    }
}