올해 1월달부터 스프링 프레임워크를 이용해 쇼핑몰 웹사이트를 구현해보는 프로젝트를 진행 중에 있다. 오늘은 스프링 프레임워크의 특징에 대해 간단히 정리해보고자 한다.
아직까지 완벽하게 개념이 정리된 건 아니고 전반적인 흐름에 대해서만 이해하고 있는 상태라 프로젝트를 구현해보며 스프링의 특징들을 직접 경험해보며 더 구체적으로 정리할 예정이다.
스프링 주요 특징
1. POJO 기반의 구성
2. 의존성 주입(DI)을 통한 객체 간의 관계 구성
3. AOP 지원
4. 편리한 MVC 구조
5. WAS의 종속적이지 않은 개발 환경
POJO 기반의 구성
POJO란 Plain Old Java Object의 약자로 다른 클래스나 인터페이스를 상속/implements 받아 메서드가 추가된 클래스가 아닌 일반적으로 우리가 알고 있는 getter, setter 같이 기본적인 기능만 가진 자바 객체를 말한다.
public class User {
private int id;
private String name;
private String email;
public int getId() {
return id;
}
public String getName() {
return name;
}
public String getEmail() {
return email;
}
public void setId(int id) {
this.id = id;
}
public void setName(String name) {
this.name = name;
}
public void setEmail(String email) {
this.email = email;
}
}위와 같은 클래스를 자바의 기본 객체라고 한다.
자바를 이용해 비즈니스 서비스를 개발할 때 비즈니스 로직 뿐만 아니라 트랜잭션, 보안 등 로우레벨의 로직까지 작성해야하는 부담감을 없애고자 EJB(Enterprise Java Beans)를 만들게 되었다. EJB를 사용하면서 로우레벨의 로직 개발에 대한 수고를 덜 수 있었지만, 한 두가지 기능을 사용하기 위해 거대한 EJB를 상속받거나 implements 하게 되어 가벼운 서비스조차도 무겁게 만들어졌고, 다른 기능으로 대체하기 위해선 전체 코드를 수정해야 하는 문제점이 발생하였다.
JAVA의 기본 개념인 객체지향에 집중하고, 특정 클래스나 라이브러리에 종속되지 않는 POJO 구성으로 코드를 작성한다면 이런 문제점을 해결할 수 있을 것이라고 생각했다.
따라서 Spring은 POJO 방식을 기반으로 한 웹 프레임워크이고, IoC와 DI, AOP 등 Spring의 주요 기술을 활용해 POJO 기반의 구성을 이루게 되었다.
아래 예시는 POJO 개념을 사용하지 않은 예시이다.
public class ExampleListener implements MessageListener {
public void onMessage(Message message) {
if (message instanceof TextMessage) {
try {
System.out.println(((TextMessage) message).getText());
}
catch (JMSException ex) {
throw new RuntimeException(ex);
}
}
else {
throw new IllegalArgumentException("Message must be of type TextMessage");
}
}
}위 코드는 JMS 라는 기능을 사용하기 위해 MessageListener 인터페이스를 상속받을 것을 알 수 있다.
이렇게 POJO 기반의 코드를 작성하지 않게 되면 이후 JMS와 기능을 비슷하지만 다른 솔루션을 사용하고자 할 때 교체하기가 굉장히 힘들어지게 된다.
아래는 POJO 기반으로 작성한 예제이다.
@Component
public class ExampleListener {
@JmsListener(destination = "myDestination")
public void processOrder(String message) {
System.out.println(message);
}
}위 예제는 JmsListner를 상속받지 않고 어노테이션을 통해 객체를 주입받은 상황이다. 이런식으로 코드를 작성하게 되면 해당 클래스와의 결합도가 낮아져 다른 솔루션으로 변경하고 할 경우 @JmsListener를 @(다른 솔루션)으로 코드를 수정만 하면 가능하므로 유지 보수에 있어 좀 더 유용하게 활용할 수 있다.
참조1
참조2
