일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 | 31 |
- 그리디알고리즘
- 다이나믹프로그래밍
- 동적계획법
- 멀티프로세서
- 다이나믹 프로그래밍
- codility
- OS
- I/O장치
- DirectX12
- 파일시스템 구현
- 운영체제
- DirectX 12
- 프로그래머스
- directx
- 디자인패턴
- 타입 객체
- 락
- 백준
- 병행성
- 영속성
- 컨디션 변수
- 자료구조
- 병행성 관련 오류
- Direct12
- 렌더링 파이프라인
- 스케줄링
- 쓰레드
- 그리디 알고리즘
- 알고리즘
- 멀티쓰레드
- Today
- Total
기록공간
스프링의 특징과 의존성 주입 본문
스프링 프레임워크의 간략한 역사
스프링이 인기있는 프레임워크가 된 이유를 이야기하려면 프레임워크가 무엇인지 알아야 한다. 프레임워크는 '뼈대나 근간을 이루는 코드들의 묶음'이라고 할 수 있다. 그럼 이 뼈대는 왜 필요한것일까?
개발자는 개개인의 능력 차이가 크며, 개발자의 구성에 따라 프로젝트의 결과 역시 큰 차이가 있다. 프레임워크는 이런 상황을 극복하기 위한 코드의 결과물이다. 프레임워크에 미리 짜여진 프로그램의 기본 흐름이나 구조에 개발자들은 자신의 코드를 추가하는 방식으로 개발하게 된다.
프레임워크의 장점은 개발에 필요한 구조를 이미 코드로 만들어 놓았다는 것이다. 이러한 장점으로 실력이 부족한 개발자라 하더라도 반쯤 완성한 상태에서 부분만 조립하는 형태의 개발이 가능하다. 회사 입장에서는 일정한 품질이 보장되는 결과물을 얻을 수 있을 뿐만 아니라, 개발자 입장에서는 완성된 구조에 자신의 코드만 개발하여 넣어주면 되므로 개발 시간을 단축할 수 있다. 수많은 프레임워크가 있지만, 그 중에서도 스프링 프레임워크는 가장 성공적인 '경량(light-weight)' 프레임워크이다.
경량 프레임워크(light-weight Framework)
경량 프레임워크라는 용어는 90년대 말 복잡한 구동환경과 HW적인 구성이 필요한 프레임워크의 반대되는 개념으로 등장했다. 과거 프레임워크는 너무나 복잡하고 방대했기에, 그 전체를 이해하고 개발하기에는 어려운 점이 많았다. 이에 경량 프레임워크는 특정 기능을 위주로 간단한 jar파일 등을 이용해 모든 개발이 가능하도록 구성된 프레임워크이다.
스프링 프레임워크 만의 차별성
많은 프레임워크들 중에서 스프링은 다음과 같은 뚜렷한 차별성이 있었다.
● 복잡함에 반기를 들어 만들어진 프레임워크
엔터프라이즈급 프레임워크들은 다양한 경우를 처리할 수 있는 다양한 기능을 가지도록 만들다 보니 너무 많은 구조가 필요했고 이로 인해 매우 복잡했다. 이러한 복잡성을 해결하기 위해 나온 프레임워크가 스프링이다. 일반적인 java 클래스와 인터페이스를 이용하는 구조로 진입장벽이 높지 않았고, 복잡한 프레임워크에 비해 가볍기 대문에 빠르게 엔터프라이즈급 시스템을 작성할 수 있다.
● 프로젝트 전체 구조를 설계할 때 유용한 프레임워크
다른 프레임워크들은 웹이나 데이터베이스 영역 등의 전문적 영역에 대해서만 지원하는 경우가 많았고, 비즈니스 로직을 처리하는 부분에 대한 설계는 개발자 역량에 맡기는 경우가 많았다. 반면 스프링은 어느 한 분야에 집중하지 않고, 전체를 설계하는 용도로 사용될 수 있었다. 스프링 프로젝트는 대부분 웹이라는 제한된 영역에서 많이 사용되지만, 근본적인 사상 자체는 OOP 구조를 뒷받침하고 구조를 설계하는 사상이다.
● 다른 프레임워크들의 포용
스프링은 전체 구조에 집중했기 때문에 특정한 영역의 프레임워크와 공존하는 방식으로 사용 할 수 있었다. 다른 프레임워크는 특정 프레임워크를 채택하기 위해 해당 영역 전체를 수정해야 하는 고질적인 문제가 있었지만, 스프링은 통합을 지원했기 때문에 최소한의 수정이 가능했다. 스프링의 최대 장점은 기본 뼈대를 흔들지 않고, 여러 종류의 프레임워크를 혼용해서 사용할 수 있다는 점이다.
● 개발 생산성과 개발도구의 지원
스프링의 경우 이론적으로 개발자가 제대로 이해해야 하는 부분이 많았지만, 결과적으로 코드의 양은 확실히 줄어들 수 있었고, 유지 보수에 있어서도 XML의 설정 등을 이용했기 때문에 환영받을 수 있었다. Eclipse 등의 플러그인 지원 역시 다른 프레임워크들에 비해 빠른 업데이트가 되었기 때문에 개발시 별도의 새로운 개발도구 적응이 필요 없었다.
스프링의 주요 특징
■ POJO 기반의 구성
스프링 프레임워크의 내부는 객체 간의 관계를 구성할 수 있는 특징을 가지고 있다. 스프링은 이 관계를 구성할 때 별도의 API 등을 사용하지 않는 POJO(Plain Old Java Object)의 구성 만으로 가능하도록 제작되어 있다. 즉, 일반적인 Java 코드를 이용해서 객체를 구성하는 방식을 그대로 스프링에서 사용할 수 있다.
이것이 중요한 이유는 코드 개발시에 개발자가 특정한 라이브러리나 컨테이너 기술에 종속적이지 않다는 것을 의미하기 때문이다. 가장 일반적인 형태로 코드를 작성하고 실행할 수 있기 때문에 생산성에서도 유리하고, 코드에 대한 테스트 작업 역시 더 유연하게 할 수 있다는 장점이 있다.
■ 의존성 주입(DI)
스프링에 대한 얘기를 하면서 빠지지 않는 개념이 바로 '의존성 주입(Dependency Injection)'이라는 개념이다.
의존성이라는 것은 하나의 객체가 다른 객체 없이 제대로 된 역할을 할 수 없다는 것을 의미한다. 음식점을 예로들면 주방장에게 문제가 생겨서 나오지 못하면 장사를 할 수 없는 일이 발생하게 된다. 의존성은 이처럼 하나의 객체가 다른 객체의 상태에 따라 영향을 받는 것을 의미한다.
주입은 말 그대로 외부에서 밀어 넣는 것을 의미한다. 외부에서 주입하는 것과 그렇지 않은 것을 이해하기 위해서 음식점의 식재료를 생각해 보면 이해가 쉽다. 어떤 음식점의 경우 매일 가게를 열기 전 직접 식재료를 구하기 위해 시장을 가지만, 프랜차이즈 식당들은 본사가 트럭을 이용해 식재료를 공급한다. 이 두 가지 방식의 차이는 필요한 객체를 얻기 위해 주체가 능동적인지 수동적인지에 대한 문제이다.
의존성과 주입을 결합해서 생각해 보면 '어떤 객체가 필요한 객체를 외부에서 밀어 넣는다'는 의미가 된다. 그렇다면 왜 외부에서 객체를 주입하는 방식을 사용하는 것일까?
앞서 음식점 예에서 대행업체에서 배송해 주는 것을 사용하는 경우 얻는 장점이 무엇이가 고민해보면 역시 '편리하다', '장사에만 집중할 수 있다'와 같은 장점들을 생각해 볼 수 있다. 이를 코드에 대입해서 살펴보면 '주입을 받는 입장에서는 어떤 객체인지 신경 쓸 필요가 없다', '어떤 객체에 의존하든 자신의 역할은 변하지 않는다' 와 같은 의미로 볼 수 있다. 의존성 주입은 다음 도형처럼 표현할 수 있다.
의존성 주입 방식을 사용하려면 ApplicationContext처럼 추가적인 하나의 존재가 필요하게 된다. 이 존재는 의존성이 필요한 객체에 필요한 객체를 찾아 주입하는 역할을 하게 된다.
스프링은 이러한 구조를 만드는 데 적합한 구조로 설계되어 있다. 스프링을 이용하면 개발자들은 기존의 프로그래밍과 달리 객체와 객체를 분리해 생성하고, 이러한 객체들을 엮는 작업을 하는 형태의 개발을 하게 된다. 스프링에서는 ApplicationContext가 관리하는 객체들을 '빈(Bean)'이라는 용어로 부르고, 빈과 빈 사이의 의존관계를 처리하는 방식으로 XML 설정, 어노테이션 설정, Java 설정 방식을 이용할 수 있다.
■ AOP의 지원
좋은 개발환경의 중요 원칙은 '개발자가 비즈니스 로직에만 집중할 수 있게 한다' 이다. 이 목표를 이루기 위해서는 몇 가지 중요한 원칙이 있지만, 가장 쉽게 생각할 수 있는 것이 '반복적인 코드의 제거'라고 할 수 있다. 스프링은 프레임워크를 이용한 개발에도 이러한 반복적인 코드를 줄이고, 핵심 비즈니스 로직에만 집중할 수 있는 방법을 제공한다.
대부분 시스템이 공통으로 가지는 보안, 로그, 트랜잭션 같이 비즈니스 로직은 아니지만, 반드시 처리가 필요한 부분을 스프링에서는 횡단 관심사(cross-concern)라고 한다. 스프링은 이러한 횡단 관심사를 분리해서 제작하는 것이 가능하다. AOP(Aspect Oriented Programming)는 이러한 횡단 관심사를 모듈로 분리하는 프로그래밍의 패러다임이다.
AOP를 통해서 개발자는 핵심 비즈니스 로직에만 집중해서 코드를 개발할 수 있게 되었고, 다른 관심사를 적용할 때 코드의 수정을 최소화시킬 수 있었으며, 원하는 관심사의 유지보수가 수월한 코드를 구성할 수 있었다.
■ 트랜잭션의 지원
데이터베이스를 이용할 때 반드시 신경 써야 하는 부분은 하나의 업무가 여러 작업으로 이루어지는 경우의 트랜잭션 처리이다. 트랜잭션 처리는 상황에 따라 복잡하게 구성될 수도, 아닐 수도 있는데, 그때마다 코드를 이용해서 처리하는 작업은 개발자에게는 상당히 피곤한 일이다. 스프링은 이런 트랜잭션 관리를 어노테이션이나 XML로 설정할 수 있기 때문에 개발자가 매번 상황에 맞는 코드를 작성할 필요가 없도록 설계되었다.
출처 : 코드로 배우는 스프링 웹 프로젝트
www.yes24.com/Product/Goods/64340061
'BackEnd > Spring' 카테고리의 다른 글
[Spring 에러] Log4j cannot be resolved to a type (0) | 2021.03.06 |
---|---|
[Spring 에러] cvc-complex-type.2.3 (0) | 2021.03.06 |
DI(Dependency Injection) (0) | 2020.12.21 |
AOP(Aspect Oriented Programming) (0) | 2020.12.21 |
Spring Framework 이해 (0) | 2020.12.21 |