위키원
"스프링 프레임워크"의 두 판 사이의 차이
잔글 |
|||
| (사용자 3명의 중간 판 23개는 보이지 않습니다) | |||
| 1번째 줄: | 1번째 줄: | ||
| − | '''스프링'''(Spring) | + | [[파일:스프링 프레임워크 로고.png|썸네일|200픽셀|'''스프링 프레임워크'''(Spring Framework)]] |
| + | [[파일:스프링 프레임워크 글자.png|썸네일|300픽셀|'''스프링 프레임워크'''(Spring Framework)]] | ||
| + | |||
| + | '''스프링 프레임워크'''(Spring Framework)는 [[자바]](Java) 기반의 응용 프로그램 개발을 지원하는 [[오픈소스]] [[표준 프레임워크]]이다. [[아파치재단]]이 관리하고 있으며, 정식 이름은 '''아파치 스프링 프레임워크'''(Apache Spring Framework)이다. 간략히 '''스프링'''이라고 부른다. 대한민국의 [[전자정부 표준 프레임워크]](eGovFrame)는 [[오픈소스]]인 스프링 프레임워크 기반으로 개발되었다. | ||
== 개요 == | == 개요 == | ||
| 5번째 줄: | 8번째 줄: | ||
== 등장배경 == | == 등장배경 == | ||
| − | + | 스프링 프레임워크의 등장은 [[EJB]] 기술의 등장으로 인해 생겨났다. EJB는 점점 [[IT]] 시스템이 복잡한 기술이 요구되어 [[자바]]의 기초적인 [[JDK]], 서버 기반의 자바기술인 [[J2EE]], [[서블릿]](Servlet), [[JSP]] 레벨의 최소한의 서버 [[프로그래밍]] [[인터페이스]]만을 가지고 복잡한 [[애플리케이션]]을 제작하는 데 어려움이 컸으며, 여러 가지 요구사항(트랜잭션처리, 상태관리, 멀티스레딩, 리소스 풀링, 보안)을 충족시켜야 하며, 애플리케이션 로직의 복잡도와 상세 기술의 복잡함을 개발자들이 한 번에 다루기가 어렵기 때문에 이런 문제들을 다루기 위해서 EJB가 등장하였다. | |
| − | 하지만 EJB는 현실에서 1%미만의 애플리케이션에서만 필요한 멀티 DB를 위한 | + | 하지만 EJB는 현실에서 1% 미만의 애플리케이션에서만 필요한 멀티 DB를 위한 분산 트랜잭션을 위해 나머지 99%의 애플리케이션도 무거운 JTA 기반의 글로벌 트랜잭션 관리 기능을 사용해야 했다. 특별한 경우가 아니라면 그다지 장점이 없는 EJB의 원격분산 모델은 성능을 떨어뜨리고 서버의 복잡도만 증가시켰다. 가장 최악의 문제점은 EJB스펙을 따르는 비즈니스 오브젝트들은 객체 지향적인 특징과 장점을 포기해야 했다는 것이다. EJB 빈은 상속과 다형성 등의 혜택을 제대로 누릴 수가 없었다. 이처럼 EJB 애플리케이션 개발의 복잡도를 제거하면서 다른 한편으로는 더 많은 문제와 복잡성을 가지고 왔다. |
| − | EJB는 형편없는 생산성과 | + | EJB는 형편없는 생산성과 느린 성능, 불필요한 기술적인 복잡도에 의해 EJB의 잘못 설계된 과도한 기술을 피하고, 객체지향 원리에 따라 만들어진 자바언어의 기본에 충실하게 비즈니스 로직을 구현하는 일명 POJO방식을 이용한 POJO프레임워크(POJO를 이용한 애플리케이션 개발이 가진 특징과 장점을 그대로 살리면서 EJB에서 제공하는 엔터프라이즈 서비스와 기술을 그대로 사용할수 있도록 도와주는 프레임워크를 개발한 것이 대표적인 스프링이다.<ref> oblab,〈[https://blog.naver.com/PostView.nhn?blogId=oblab&logNo=150136305165&proxyReferer=https%3A%2F%2Fwww.google.com%2F ◆ 스프링프레임워크의 등장배경 ◆]〉, 《네이버블로그》</ref> |
== 역사 == | == 역사 == | ||
| 25번째 줄: | 28번째 줄: | ||
== 특징 == | == 특징 == | ||
| − | *의존성 주입(Dependency Injection, DI) | + | * 의존성 주입(Dependency Injection, DI) : 의존 관계 주입. 각각의 계층이나 서비스 간에 의존성이 존재할 경우 Spring이 서로 연결시켜준다. POJO 객체들 사이의 의존 관계를 Spring이 알아서 연관성을 맺어준다. 예) 다양한 DB 사용이 가능 |
| − | 의존 관계 주입 | ||
| − | 각각의 계층이나 | ||
| − | POJO 객체들 사이의 의존 관계를 Spring이 알아서 연관성을 맺어준다. | ||
| − | |||
| − | *관점 지향 프로그래밍(Aspect Orientated Programming, AOP) | + | * 관점 지향 프로그래밍(Aspect Orientated Programming, AOP) : 관점 중심 [[프로그래밍]]. Spring은 핵심적인 비즈니스 로직과 관련이 없으나 여러 곳에서 공통으로 쓰이는 기능들을 분리(공통 관심사를 분리)하여 개발하고 실행 시에 서로 조합할 수 있는 AOP를 지원한다. 이를 통해 코드를 단순하고 깔끔하게 작성할 수 있다. 횡단 관심을 수행하는 코드(Logging, Security, Transaction 등)는 aspect라는 특별한 객체로 모듈화하고 weaving이라는 작업을 통해 모듈화한 코드를 핵심 기능에 끼워 넣을 수 있다. |
| − | 관점 중심 [[프로그래밍]] | ||
| − | Spring은 핵심적인 비즈니스 로직과 관련이 없으나 여러 곳에서 | ||
| − | 이를 통해 코드를 단순하고 깔끔하게 작성할 수 있다. | ||
| − | 횡단 관심을 수행하는 코드(Logging, Security, Transaction 등)는 aspect라는 특별한 객체로 모듈화하고 weaving이라는 작업을 통해 모듈화한 코드를 핵심 기능에 | ||
| − | *Portable Service Abstraction | + | * Portable Service Abstraction : 이식 가능한 서비스 추상화. Spring은 완성도가 높은 [[라이브러리]]와 연결할 수 있는 [[인터페이스]]를 제공한다. 즉, 다른 프레임워크들과의 통합을 지원한다.<ref> HeeJeong Kwon, 〈[https://gmlwjd9405.github.io/2018/10/26/spring-framework.html (Spring) Spring Framework란]〉, 《깃허브》</ref> |
| − | 이식 가능한 서비스 추상화 | ||
| − | Spring은 완성도가 높은 [[라이브러리]]와 연결할 수 있는 [[인터페이스]]를 제공한다. | ||
| − | 즉, 다른 프레임워크들과의 통합을 지원한다.<ref> HeeJeong Kwon, | ||
| − | *POJO | + | * [[포조]](POJO; Plain Old Java Object) 방식 : Java EE를 사용하면서 해당 플랫폼에 종속된 무거운 객체들을 만드는 것에 반발하며 나타난 용어다. 별도의 [[프레임워크]] 없이 Java EE를 사용할 때에 비해 특정 [[인터페이스]]를 직접 구현하거나 상속받을 필요가 없어 기존 라이브러리를 지원하기가 용이하고, 객체가 가볍다. |
| − | Java EE를 사용하면서 해당 플랫폼에 | ||
| − | *제어 반전(Inversion of Control, IoC) | + | * 제어 반전(Inversion of Control, IoC) : 전통적인 프로그래밍에서는 개발자가 작성한 프로그램이 외부 라이브러리의 코드를 호출해서 이용했다. 제어 반전은 이와 반대로 외부 라이브러리 코드가 개발자의 코드를 호출하게 된다. 즉, 제어권이 프레임워크에게 있어 필요에 따라 스프링 프레임워크가 사용자의 코드를 호출한다. |
| − | 전통적인 프로그래밍에서는 개발자가 작성한 프로그램이 외부 라이브러리의 코드를 호출해서 이용했다. 제어 반전은 이와 반대로 외부 라이브러리 코드가 개발자의 코드를 호출하게 된다. 즉, 제어권이 프레임워크에게 있어 필요에 따라 스프링 프레임워크가 사용자의 코드를 호출한다. | ||
| − | *다양한 서비스 | + | * 다양한 서비스 : [[마이바티스]](myBatis)와 같은 데이터베이스 처리 라이브러리나 tiles 같은 유용한 인터페이스를 제공한다.<ref name="나무위키> 〈[https://namu.wiki/w/Spring(%ED%94%84%EB%A0%88%EC%9E%84%EC%9B%8C%ED%81%AC) 스프링]〉,《나무위키》 </ref> |
| − | |||
== 모듈 == | == 모듈 == | ||
스프링에서 사용되는 주요 모듈은 다음과 같다. | 스프링에서 사용되는 주요 모듈은 다음과 같다. | ||
| − | *제어 반전 컨테이너 | + | * 제어 반전 컨테이너 :제어 반전(IoC: Inversion of Control) 컨테이너는 스프링의 가장 중요하고 핵심적인 기능으로서 [[자바]]의 반영(reflection)을 이용해서 객체의 생명주기를 관리하고 의존성 주입(Dependency Injection)을 통해 각 계층이나 서비스들간의 의존성을 맞춰준다. 이러한 기능들은 주로 환경설정을 담당하는 XML 파일에 의해 설정되고 수행된다. |
| − | 제어 반전(IoC: Inversion of Control) 컨테이너는 스프링의 가장 중요하고 핵심적인 기능으로서 [[자바]]의 반영(reflection)을 이용해서 객체의 생명주기를 관리하고 의존성 주입(Dependency Injection)을 통해 각 계층이나 서비스들간의 의존성을 맞춰준다. 이러한 기능들은 주로 환경설정을 담당하는 XML 파일에 의해 설정되고 수행된다. | ||
| − | *관점 지향 프로그래밍 프레임워크 | + | * 관점 지향 프로그래밍 프레임워크 : 스프링은 로깅이나 보안, 트랜잭션 등 핵심적인 비즈니스 로직과 관련이 없으나 여러 곳에서 공통으로 쓰이는 기능들을 분리하여 개발하고 실행 시에 서로 조합할 수 있는 관점 지향 [[프로그래밍]](AOP)을 지원한다. 기존에 널리 사용되고 있는 강력한 관점 지향 프로그래밍 프레임워크인 AspectJ도 내부적으로 사용할 수 있으며, 스프링 자체적으로 지원하는 실행시(Runtime)에 조합하는 방식도 지원한다. |
| − | 스프링은 로깅이나 보안, 트랜잭션 등 핵심적인 비즈니스 로직과 관련이 없으나 여러 곳에서 | ||
| − | *데이터 액세스 프레임워크 | + | * 데이터 액세스 프레임워크 : 스프링은 데이터베이스에 접속하고 자료를 저장 및 읽어오기 위한 여러 가지 유명한 [[라이브러리]], 즉 JDBC, iBATIS(MyBatis), Hibernate 등에 대한 지원 기능을 제공하여 데이터베이스 프로그래밍을 쉽게 사용할 수 있다. |
| − | 스프링은 데이터베이스에 접속하고 자료를 저장 및 읽어오기 위한 여러 가지 유명한 [[라이브러리]], 즉 JDBC, iBATIS(MyBatis), Hibernate 등에 대한 지원 기능을 제공하여 데이터베이스 프로그래밍을 쉽게 사용할 수 있다. | ||
| − | *트랜잭션 관리 프레임워크 | + | * 트랜잭션 관리 프레임워크 : 스프링은 추상화된 트랜잭션 관리를 지원하며 XML 설정파일 등을 이용한 선언적인 방식 및 프로그래밍을 통한 방식을 모두 지원한다. |
| − | 스프링은 추상화된 트랜잭션 관리를 지원하며 XML 설정파일 등을 이용한 선언적인 방식 및 프로그래밍을 통한 방식을 모두 지원한다. | ||
| − | *모델-뷰-컨트롤러 패턴 | + | * 모델-뷰-컨트롤러 패턴 : 스프링은 웹 프로그램밍 개발 시 거의 표준적인 방식인 Spring MVC라 불리는 모델-뷰-컨트롤러(MVC) 패턴을 사용한다. DispatcherServlet이 Controller 역할을 담당하여 각종 요청을 적절한 서비스에 분산시켜주며 이를 각 서비스가 처리를 하여 결과를 생성하고 그 결과는 다양한 형식의 View 서비스들로 화면에 표시될 수 있다. |
| − | 스프링은 웹 프로그램밍 개발 시 거의 표준적인 방식인 Spring MVC라 불리는 모델-뷰-컨트롤러(MVC) 패턴을 사용한다. DispatcherServlet이 Controller 역할을 담당하여 각종 요청을 적절한 서비스에 분산시켜주며 이를 각 | ||
| − | *배치 프레임워크 | + | * 배치 프레임워크 : 스프링은 특정 시간대에 실행하거나 대용량의 자료를 처리하는 데 쓰이는 일괄 처리(Batch Processing)을 지원하는 배치 프레임워크를 제공한다. 기본적으로 스프링 배치는 Quartz 기반으로 동작한다.<ref name="위키백과"></ref> |
| − | 스프링은 특정 시간대에 실행하거나 대용량의 자료를 | ||
== 문제점 == | == 문제점 == | ||
| − | 선택적으로 도입할 수 없는 복잡한 기술 | + | *선택적으로 도입할 수 없는 복잡한 기술 |
스프링은 거대한 소프트웨어의 개발을 편리하게 하기 위해 특별한 기술을 기반으로 움직인다. 의존성 주입(DI; Dependency Injection)이라고도 불리는 제어의 역전(IoC; Inversion of Control)과, 관점 지향 프로그래밍(AOP: Aspect Oriented Programming)이 그것이다. | 스프링은 거대한 소프트웨어의 개발을 편리하게 하기 위해 특별한 기술을 기반으로 움직인다. 의존성 주입(DI; Dependency Injection)이라고도 불리는 제어의 역전(IoC; Inversion of Control)과, 관점 지향 프로그래밍(AOP: Aspect Oriented Programming)이 그것이다. | ||
| + | 이러한 기술이 언제나 효과적이지는 않다. 제어의 역전은 객체 사이의 의존도를 떨어트린다는 장점이 있다. 그러나 어느 정도 규모 있는 소프트웨어가 아닌 이상 의존성이 바뀔 일이 무척 적다. 정말 다른 객체에 의존하도록 해야 한다면, 그때 코드를 수정하면 된다.제어의 역전은 사실 그렇게 어려운 기술이 아니다. 프레임워크를 통하지 않고 수동으로 적용한다면 누구나 이해할 수 있다. 하지만 프레임워크에서 제공하는 기술을 사용한다면 모두가 해당 기술에 대해 알고 있어야만 한다. | ||
| − | + | *너무 다양한 방법 제시 | |
| − | |||
| − | |||
| − | |||
| − | 너무 다양한 방법 제시 | ||
스프링은 특정한 문제를 해결할 수 있는 단 한 가지의 방법 대신, 여러 방법을 동시에 제공하는 경우가 매우 많다. | 스프링은 특정한 문제를 해결할 수 있는 단 한 가지의 방법 대신, 여러 방법을 동시에 제공하는 경우가 매우 많다. | ||
이처럼 스프링은 다양한 선택지를 제시하여 프로젝트마다 각각의 방식을 추구할 수 있도록 도와준다. 그러나 무언가를 결정하는 것은 누구나 할 수 있는 일이 아니다. 충분한 자료 조사와 학습이 필요하다. | 이처럼 스프링은 다양한 선택지를 제시하여 프로젝트마다 각각의 방식을 추구할 수 있도록 도와준다. 그러나 무언가를 결정하는 것은 누구나 할 수 있는 일이 아니다. 충분한 자료 조사와 학습이 필요하다. | ||
| − | + | 스프링 문서는 특정한 방식을 직접적으로 권장하는 일이 드물다. 만약 똑같은 문제를 해결할 수 있는 대안 기능이 나온다고 할지라도, 스프링은 옛 기능을 ‘또다른 해결책’으로서 남겨두는 경우가 대부분이다.<ref name="문제점과대안"> 방성범 (Bang Seongbeom), <[https://www.bangseongbeom.com/spring-downsides-alternatives.html 스프링의 단점과 대안]>, 《개인블로그》</ref> | |
| − | 스프링 문서는 특정한 방식을 직접적으로 권장하는 일이 드물다. 만약 똑같은 문제를 해결할 수 있는 대안 기능이 나온다고 할지라도, 스프링은 옛 기능을 ‘또다른 해결책’으로서 남겨두는 경우가 대부분이다. | ||
{{ 각주 }} | {{ 각주 }} | ||
== 참고자료 == | == 참고자료 == | ||
| − | * | + | * 스프링 프레임워크 공식 홈페이지 - https://spring.io/ |
* HeeJeong Kwon, 〈[https://gmlwjd9405.github.io/2018/10/26/spring-framework.html (Spring) Spring Framework란]〉, 《깃허브》, 2018-10-26 | * HeeJeong Kwon, 〈[https://gmlwjd9405.github.io/2018/10/26/spring-framework.html (Spring) Spring Framework란]〉, 《깃허브》, 2018-10-26 | ||
* oblab, 〈[https://blog.naver.com/PostView.nhn?blogId=oblab&logNo=150136305165&proxyReferer=https%3A%2F%2Fwww.google.com%2F ◆ 스프링프레임워크의 등장배경 ◆]〉, 《네이버블로그》, 2012-04-13 | * oblab, 〈[https://blog.naver.com/PostView.nhn?blogId=oblab&logNo=150136305165&proxyReferer=https%3A%2F%2Fwww.google.com%2F ◆ 스프링프레임워크의 등장배경 ◆]〉, 《네이버블로그》, 2012-04-13 | ||
| + | * 방성범 (Bang Seongbeom), 〈[https://www.bangseongbeom.com/spring-downsides-alternatives.html 스프링의 단점과 대안]〉, 《개인블로그》, 2018-11-15 | ||
== 같이 보기 == | == 같이 보기 == | ||
| 97번째 줄: | 77번째 줄: | ||
* [[아파치재단]] | * [[아파치재단]] | ||
* [[오픈소스]] | * [[오픈소스]] | ||
| − | *[[자바]] | + | * [[자바]] |
| − | {{ | + | * [[EJB]] |
| + | * [[스프링]] | ||
| + | |||
| + | {{솔루션|검토 필요}} | ||
2021년 8월 20일 (금) 23:38 기준 최신판
스프링 프레임워크(Spring Framework)는 자바(Java) 기반의 응용 프로그램 개발을 지원하는 오픈소스 표준 프레임워크이다. 아파치재단이 관리하고 있으며, 정식 이름은 아파치 스프링 프레임워크(Apache Spring Framework)이다. 간략히 스프링이라고 부른다. 대한민국의 전자정부 표준 프레임워크(eGovFrame)는 오픈소스인 스프링 프레임워크 기반으로 개발되었다.
개요[편집]
자바 플랫폼을 위한 오픈 소스 애플리케이션 프레임워크로서 간단히 스프링(spring)이라고 한다. 동적인 웹 사이트 개발을 위한 여러 가지 서비스를 제공한다. EJB 기반으로 개발을 하지 않고 POJO(Plain Old Java Object) 기반으로 개발을 하더라도 가볍고, 제어가 가능한 상호 관련이 적은, AOP(Aspect Oriented Programming. 관점지향 프로그래밍)을 지원하고, 컨테이너를 통해 라이프사이클을 관리하고, XML 기반으로 컴포넌트를 개발할 수 있도록 지원해주는 프레임워크를 말한다.[1]
등장배경[편집]
스프링 프레임워크의 등장은 EJB 기술의 등장으로 인해 생겨났다. EJB는 점점 IT 시스템이 복잡한 기술이 요구되어 자바의 기초적인 JDK, 서버 기반의 자바기술인 J2EE, 서블릿(Servlet), JSP 레벨의 최소한의 서버 프로그래밍 인터페이스만을 가지고 복잡한 애플리케이션을 제작하는 데 어려움이 컸으며, 여러 가지 요구사항(트랜잭션처리, 상태관리, 멀티스레딩, 리소스 풀링, 보안)을 충족시켜야 하며, 애플리케이션 로직의 복잡도와 상세 기술의 복잡함을 개발자들이 한 번에 다루기가 어렵기 때문에 이런 문제들을 다루기 위해서 EJB가 등장하였다.
하지만 EJB는 현실에서 1% 미만의 애플리케이션에서만 필요한 멀티 DB를 위한 분산 트랜잭션을 위해 나머지 99%의 애플리케이션도 무거운 JTA 기반의 글로벌 트랜잭션 관리 기능을 사용해야 했다. 특별한 경우가 아니라면 그다지 장점이 없는 EJB의 원격분산 모델은 성능을 떨어뜨리고 서버의 복잡도만 증가시켰다. 가장 최악의 문제점은 EJB스펙을 따르는 비즈니스 오브젝트들은 객체 지향적인 특징과 장점을 포기해야 했다는 것이다. EJB 빈은 상속과 다형성 등의 혜택을 제대로 누릴 수가 없었다. 이처럼 EJB 애플리케이션 개발의 복잡도를 제거하면서 다른 한편으로는 더 많은 문제와 복잡성을 가지고 왔다.
EJB는 형편없는 생산성과 느린 성능, 불필요한 기술적인 복잡도에 의해 EJB의 잘못 설계된 과도한 기술을 피하고, 객체지향 원리에 따라 만들어진 자바언어의 기본에 충실하게 비즈니스 로직을 구현하는 일명 POJO방식을 이용한 POJO프레임워크(POJO를 이용한 애플리케이션 개발이 가진 특징과 장점을 그대로 살리면서 EJB에서 제공하는 엔터프라이즈 서비스와 기술을 그대로 사용할수 있도록 도와주는 프레임워크를 개발한 것이 대표적인 스프링이다.[2]
역사[편집]
로드 존슨이 2002년에 출판한 자신의 저서인 Expert One-on-One J2EE Design and Developement 에 선보인 코드를 기반으로 시작하여 점점 발전하게 되었다. 이 프레임워크는 2003년 6월에 최초로 아파치 2.0 라이선스로 공개되었으며 주요 버전 이력은 다음과 같다.
- 2004년 3월 : 1.0
- 2006년 10월 : 2.0
- 2007년 11월 : 2.5
- 2009년 12월 : 3.0
- 2011년 12월 : 3.1
- 2013년 12월 : 4.0
- 2017년 9월 : 5.0
2006년에 1.2.6 버전으로 Jolt Productive Award 와 Jax Innovation Award 를 수상하였다.[3]
특징[편집]
- 의존성 주입(Dependency Injection, DI) : 의존 관계 주입. 각각의 계층이나 서비스 간에 의존성이 존재할 경우 Spring이 서로 연결시켜준다. POJO 객체들 사이의 의존 관계를 Spring이 알아서 연관성을 맺어준다. 예) 다양한 DB 사용이 가능
- 관점 지향 프로그래밍(Aspect Orientated Programming, AOP) : 관점 중심 프로그래밍. Spring은 핵심적인 비즈니스 로직과 관련이 없으나 여러 곳에서 공통으로 쓰이는 기능들을 분리(공통 관심사를 분리)하여 개발하고 실행 시에 서로 조합할 수 있는 AOP를 지원한다. 이를 통해 코드를 단순하고 깔끔하게 작성할 수 있다. 횡단 관심을 수행하는 코드(Logging, Security, Transaction 등)는 aspect라는 특별한 객체로 모듈화하고 weaving이라는 작업을 통해 모듈화한 코드를 핵심 기능에 끼워 넣을 수 있다.
- Portable Service Abstraction : 이식 가능한 서비스 추상화. Spring은 완성도가 높은 라이브러리와 연결할 수 있는 인터페이스를 제공한다. 즉, 다른 프레임워크들과의 통합을 지원한다.[4]
- 포조(POJO; Plain Old Java Object) 방식 : Java EE를 사용하면서 해당 플랫폼에 종속된 무거운 객체들을 만드는 것에 반발하며 나타난 용어다. 별도의 프레임워크 없이 Java EE를 사용할 때에 비해 특정 인터페이스를 직접 구현하거나 상속받을 필요가 없어 기존 라이브러리를 지원하기가 용이하고, 객체가 가볍다.
- 제어 반전(Inversion of Control, IoC) : 전통적인 프로그래밍에서는 개발자가 작성한 프로그램이 외부 라이브러리의 코드를 호출해서 이용했다. 제어 반전은 이와 반대로 외부 라이브러리 코드가 개발자의 코드를 호출하게 된다. 즉, 제어권이 프레임워크에게 있어 필요에 따라 스프링 프레임워크가 사용자의 코드를 호출한다.
모듈[편집]
스프링에서 사용되는 주요 모듈은 다음과 같다.
- 제어 반전 컨테이너 :제어 반전(IoC: Inversion of Control) 컨테이너는 스프링의 가장 중요하고 핵심적인 기능으로서 자바의 반영(reflection)을 이용해서 객체의 생명주기를 관리하고 의존성 주입(Dependency Injection)을 통해 각 계층이나 서비스들간의 의존성을 맞춰준다. 이러한 기능들은 주로 환경설정을 담당하는 XML 파일에 의해 설정되고 수행된다.
- 관점 지향 프로그래밍 프레임워크 : 스프링은 로깅이나 보안, 트랜잭션 등 핵심적인 비즈니스 로직과 관련이 없으나 여러 곳에서 공통으로 쓰이는 기능들을 분리하여 개발하고 실행 시에 서로 조합할 수 있는 관점 지향 프로그래밍(AOP)을 지원한다. 기존에 널리 사용되고 있는 강력한 관점 지향 프로그래밍 프레임워크인 AspectJ도 내부적으로 사용할 수 있으며, 스프링 자체적으로 지원하는 실행시(Runtime)에 조합하는 방식도 지원한다.
- 데이터 액세스 프레임워크 : 스프링은 데이터베이스에 접속하고 자료를 저장 및 읽어오기 위한 여러 가지 유명한 라이브러리, 즉 JDBC, iBATIS(MyBatis), Hibernate 등에 대한 지원 기능을 제공하여 데이터베이스 프로그래밍을 쉽게 사용할 수 있다.
- 트랜잭션 관리 프레임워크 : 스프링은 추상화된 트랜잭션 관리를 지원하며 XML 설정파일 등을 이용한 선언적인 방식 및 프로그래밍을 통한 방식을 모두 지원한다.
- 모델-뷰-컨트롤러 패턴 : 스프링은 웹 프로그램밍 개발 시 거의 표준적인 방식인 Spring MVC라 불리는 모델-뷰-컨트롤러(MVC) 패턴을 사용한다. DispatcherServlet이 Controller 역할을 담당하여 각종 요청을 적절한 서비스에 분산시켜주며 이를 각 서비스가 처리를 하여 결과를 생성하고 그 결과는 다양한 형식의 View 서비스들로 화면에 표시될 수 있다.
- 배치 프레임워크 : 스프링은 특정 시간대에 실행하거나 대용량의 자료를 처리하는 데 쓰이는 일괄 처리(Batch Processing)을 지원하는 배치 프레임워크를 제공한다. 기본적으로 스프링 배치는 Quartz 기반으로 동작한다.[3]
문제점[편집]
- 선택적으로 도입할 수 없는 복잡한 기술
스프링은 거대한 소프트웨어의 개발을 편리하게 하기 위해 특별한 기술을 기반으로 움직인다. 의존성 주입(DI; Dependency Injection)이라고도 불리는 제어의 역전(IoC; Inversion of Control)과, 관점 지향 프로그래밍(AOP: Aspect Oriented Programming)이 그것이다. 이러한 기술이 언제나 효과적이지는 않다. 제어의 역전은 객체 사이의 의존도를 떨어트린다는 장점이 있다. 그러나 어느 정도 규모 있는 소프트웨어가 아닌 이상 의존성이 바뀔 일이 무척 적다. 정말 다른 객체에 의존하도록 해야 한다면, 그때 코드를 수정하면 된다.제어의 역전은 사실 그렇게 어려운 기술이 아니다. 프레임워크를 통하지 않고 수동으로 적용한다면 누구나 이해할 수 있다. 하지만 프레임워크에서 제공하는 기술을 사용한다면 모두가 해당 기술에 대해 알고 있어야만 한다.
- 너무 다양한 방법 제시
스프링은 특정한 문제를 해결할 수 있는 단 한 가지의 방법 대신, 여러 방법을 동시에 제공하는 경우가 매우 많다.
이처럼 스프링은 다양한 선택지를 제시하여 프로젝트마다 각각의 방식을 추구할 수 있도록 도와준다. 그러나 무언가를 결정하는 것은 누구나 할 수 있는 일이 아니다. 충분한 자료 조사와 학습이 필요하다. 스프링 문서는 특정한 방식을 직접적으로 권장하는 일이 드물다. 만약 똑같은 문제를 해결할 수 있는 대안 기능이 나온다고 할지라도, 스프링은 옛 기능을 ‘또다른 해결책’으로서 남겨두는 경우가 대부분이다.[6]
각주[편집]
- ↑ 〈스프링〉,《네이버지식백과》
- ↑ oblab,〈◆ 스프링프레임워크의 등장배경 ◆〉, 《네이버블로그》
- ↑ 3.0 3.1 〈스프링〉,《위키백과》
- ↑ HeeJeong Kwon, 〈(Spring) Spring Framework란〉, 《깃허브》
- ↑ 〈스프링〉,《나무위키》
- ↑ 방성범 (Bang Seongbeom), <스프링의 단점과 대안>, 《개인블로그》
참고자료[편집]
- 스프링 프레임워크 공식 홈페이지 - https://spring.io/
- HeeJeong Kwon, 〈(Spring) Spring Framework란〉, 《깃허브》, 2018-10-26
- oblab, 〈◆ 스프링프레임워크의 등장배경 ◆〉, 《네이버블로그》, 2012-04-13
- 방성범 (Bang Seongbeom), 〈스프링의 단점과 대안〉, 《개인블로그》, 2018-11-15
같이 보기[편집]
