스프링&웹 | 웹애플리케이션의 문제점 & 스프링의 해결

웹 애플리케이션이 안고 있는 문제점

=> 스프링을 이용하지 않을때의 문제점

=> 스프링 이용시 해결 가능한 것들!

 

 

 

● 오브젝트의 생명주기 문제

웹애플리케이션의 프레젠테이션 층에는 컨트롤러가 Servlet이다. (MVC2 모델 채용)

(recall: 웹애플리케이션의 프레젠테이션 부분에서 UI, 컨트롤러를 담당)

Servlet 특징 : View에 액세스하는 유저 증가시 인스턴스화 하는 것이 많아져 가비지컬렉션 성능저하와 메모리 압박을 받을 수 있어서 멀티스레드로 동작한다. 그러나 멀티스레드로 동작하더라도 언제든 그러한 문제점이 일어날 수 있다. 

그래서 서비스 로직의 오브젝트를 싱글턴으로 구현해서 그러한 문제점을 방지할 수도 있지만, 이 또한 새로운 문제가 많다(65p 참고)

스프링은 이렇게 난감한 오브젝트의 생명주기를 관리해준다. 

 

 

● 부품화의 문제

인터페이스를 끼워넣으면 오브젝트 사이를 약한 결합으로 유지할 수 있어서 좋다. 그리고 인터페이스를 상속하는 오브젝트가 미완성이더라도 mock 오브젝트로 잠시 넣어두면 개발을 중단하지 않아도 된다. 마치 서로 의존하지 않는 부품처럼 생각하여 개발이 쉬워진다. 

다만 스프링과 같은 프레임워크를 이용하지 않고 '인터페이스 의존', '구현 비의존'을 실현하기 위해서는 고도의 기술이 필요하다. (: 단순히 인터페이스를 이용하는 것만으로는 구현 비의존을 실현 불가)

+ 구현 의존과 구현 비의존이란?

ㅡ 구현 의존

Let : 클래스 R ......... 인터페이스Q ........... Q구현 클래스 QImpl

클래스 R에서 Q q = new QImpl(); 라는 코드가 있다고 하자. 

지금은 구현클래스로 QImpl를 이용하고 있지만 QImpl2로 바꿔야 한다면, 

클래스 R의 소스코드 수정이 필요하다. 

 

ㅡ 구현 비의존

위와는 다르게 QImpl을 QImpl2로 대체하더라도 클래스 R의 소스코드 수정이 불필요한 경우이다.

R의 소스코드 : Q q = (Q)Factory.create(key); 따위로 작성할 수 있다. 

R이 Factory에 생성을 요구하고, Factory가 인스턴스를 생성해주는 과정이다.

(new 연산자 쓰지 않음 by 자바의 리플렉션 기능)

key는 외부파일에서 얻는다. 

=> 팩토리 메서드를 도입해서 구현 비의존을 실현할 수 있다.

=> 팩토리 메서드는 디자인패턴 중 하나이다.

'인터페이스 의존'과 '구현 비의존'은 개발 효율과 변경/확장, 테스트를 위해 필요하지만, 현실에서 급하게 소프트웨어를 만들다보면 이러한 것들은 뒤로한채 조악한 시스템을 만들어버리는 경우가 생긴다. 

그래서 스프링 프레임워크를 사용하여 '인터페이스 의존'과 '구현 비의존'을 실현하려는 것이다. 

 

 

● 기술 은닉의 필요성

∨ 개발자가 다 할수는 없다 : 만약 트랜젝션 제어를 초보 개발자에게 시키면 트랜잭션 오류가 빈발 가능

=> 트랜잭션 제어를 개발자에게 은닉하기 위한 프레임워크를 이용해야겠다.

=> 즉 기술 은닉이 필요

∨ 여러 클래스에 걸친 난잡한 트랜잭션, 예외처리, 로깅처리

: 가독성 저하, 유닛테스트 어렵게 함, 부품화 어려워짐

 

 

 

위와 같은 어쩔 수 없는 웹애플리케이션의 문제점들은 스프링에게 맡기면 된다. 

○ 오브젝트 생명 주기 문제 : DI 컨테이너로 해결

○ 부품화 문제 : DI 컨테이너로 해결

○ 기술 은닉 문제 : AOP로 해결