728x90
반응형

 5) AOP Proxy (AOP 프록시)

 

  5-1) 프록시(Proxy)란?

 

 - 클라이언트가 사용하려고 하는 실제 대상인 것처럼 위장하여 클라이언트 클라이언트의 요청을 받아주어 처리하는 대리자 역할.

프록시의 단어 자체로는 '대리인'이라는 의미를 내포하고 있음. 스프링 AOP에서의 프록시란 말그대로 대리하여 업무를 처리. 함수 호출자는 주요 업무가 아닌 보조 업무를 프록시에게 맡기고, 프록시는 내부적으로 이러한 보조 업무를 처리.

 

이렇게 함으로써, 주 업무 코드는 보조 업무가 필요한 경우, 해당 Proxy 만 추가하면 되고, 필요없게 되면 Proxy를 제거하면 됨.

보조 업무의 탈 부착이 쉬워지고, 그리하여 주 업무 코드는 보조 업무 코드의 변경으로 인해서 발생하는 코드 수정 작업이 필요 없게 됨.

 

 

 

- 프록시의 호출 및 처리 순서 -

1) Proxy 호출
2) 보조 업무 처리
3) Proxy 처리 함수(메서드) 가 실제 구현 함수(메서드) 호출 및 주 업무 처리
4) 제어권이  다시 Proxy 함수(메서드)로 넘어오고 나머지 보조 업무 처리
5) 처리 작업 완료 후, 호출 함수(메서드)로 반환.

 

  5-2) 프록시의 사용 목적

 * 클라이언트가 타깃(Target)에 접근하는 방법을 제어.

 * 타깃에 부가적인 기능을 부여.

 

 (실제 이러한 목적으로 어떻게 사용되는지는 아래에서 보자!)

 

  5-3) 프록시 구현

 

 * 먼저 사칙 연산을 위한 인터페이스(Interface)와 실제 기능을 구현한 클래스(Class) 정의.

// 사칙 연산을 정의하는 인터페이스

package aoptest;

 

public interface Calculator {

    public int add(int x, int y);

    public int subtract(int x, int y);

    public int multiply(int x, int y);

    public int divide(int x, int y);

}

 

 

// 사칙 연산을 구현하는 클래스

package aoptest;

 

public class myCalculator implements Calculator {

   

    @Override

    public int add(int x, int y) {

        return x + y;

    }

   

    @Override

    public int subtract(int x, int y) {

        return x – y;

    }

   

    @Override

    public int multiply(int x, int y) {

        return x * y;

    }

 

    @Override

    public int divide(int x, int y) {

        return x / y;

    }

}

 

 

 

// 실제 위의 사칙연산 클래스를 사용하는 예제 코드

public static void main(String[] args) {

    Calculator cal = new myCalculator(); // 다형성 

    System.out.println(cal.add(3, 4)); // add 메서드를 호출하여 3 + 4 결과를 출력

}

 

 

여기서!!

실제 사칙 연산을 하는데에 있어서 실제 소요되는 시간 측정 이라는 기능이 필요하다고 가정하자!

그렇다면 어떻게 해야 할까?

 

위의 예제 코드에서 cal.add(3, 4) 를 사용하고 있으니, 이 시간 측정을 위한 코드를 일단 myCalculator 클래스의 add 메서드에 추가하여 보자!

 

package aoptest;

 

public class myCalculator implements Calculator {

   

    @Override

    public int add(int x, int y) {

 

 // 보조 업무 (시간 측정 시작 & 로그 출력)

Log log = LogFactory.getLog(this.getClass());

StopWatch sw = new StopWatch();

sw.start();

log.info(“Timer Begin”);

 

int sum = x + y; // 주 업무 (덧셈 연산)

 

 // 보조 업무 (시간 측정 끝 & 측정 시간 로그 출력)

sw.stop();

log.info(“Timer Stop – Elapsed Time : ”+ sw.getTotalTimeMillis());

 

return sum;

    }

 

 

...

 

}

 

 

위와 같이 시간을 측정하기 위한 업무(실제 연산 업무가 아니기 때문에 보조 업무)가 add 메서드에 추가됨.

하지만, 시간 측정을 위한 이러한 코드를 add 메서드 뿐만 아니라, subtract, multiply, divide 메서드에도 추가해 주어야 하고, 설령 측정 방식이 달라지거나 로그 출력 내용이 변경 되기라도 한다면 모든 메서드를 수정해야 한다. 게다가 연산을 위한 주 업무 코드를 수정하는 것도 아니다.

 

 

그렇다면 좀 더 코드를 깔끔하게 하고, 관리도 쉽게 하고, 직관적인 프로그래밍을 위해서는 어떻게 변화를 줄 수 있을까?

바로 방금(또 이전 포스팅에서) 배운 주 업무와 보조 업무를 분리(크로스 컷팅, Cross Cutting)하고 보조 업무를 프록시(Proxy)에게 넘긴다!

 

 

AOP Proxy 를 구현한 예제 코드

// 보조 업무를 처리할 프록시 클래스 정의 (여기서는 LogPrintHandler 라 이름 지었음)

public class LogPrintHandler implements InvocationHandler { // 프록시 클래스 (핸들러)

    private Object target; // 객체에 대한 정보

 

    public LogPrintHandler(Object target) { // 생성자

        this.target = target;

    }

 

    @Override

    public Object invoke(Object proxy, Method method, Object[] args) throws Throwable   {

        Log log = LogFactory.getLog(this.getClass());

        StopWatch sw = new StopWatch();

        sw.start();

        log.info(“Timer Begin”);

        int result = (intmethod.invoke(target, args); // (3) 주업무를 invoke 함수를 통해 호출

        sw.stop();

        log.info(“Timer Stop – Elapsed Time : ”+ sw.getTotalTimeMillis());

        return result;

}

 

 

 

public static void main(String[] args) {

    Calculator cal = new myCalculator();

 

    Calculator proxy_cal = (Calculator) Proxy.newProxyInstance// (1)

        cal.getClass().getClassLoader(),  // Loader

        cal.getClass().getInterfaces(), // Interface

        new LogPrintHandler(cal)); // Handler (보조 업무를 구현하고 있는 실제 클래스)

 

    System.out.println(proxy_cal.add(3, 4));    // (2) 주 업무 처리 클래스의 add 메서드를 호출

}

 

 

 

위의 클래스와 메서드에 대한 설명.

* (1) InvocationHandler 인터페이스를 구현한 객체는 invoke 메소드를 구현해야 함. 
  해당 객체에 의하여 요청 받은 메소드를 리플렉션 API를 사용하여 실제 타깃이 되는 객체의 메소드를 호출해준다. (실제 LogPrintHandler 클래스의 invoke 메서드 내에서 method.invoke(target, args) 메서드를 호출하는데, 이는 주 업무의 메서드를 호출하는 것. main 메서드에서 Proxy.newProxyInstance 를 통해 주 업무를 처리할 클래스(myCalculator)와 보조 업무를 처리할 Proxy 클래스를 결합.

 

  - cal(변수) 실제 객체를 proxy_cal(변수) 객체에 핸들러를 통해서 전달. (LogPrintHandler())

  - getClassLoader() : 동적으로 생성되는 다이내믹 프록시 클래스의 로딩에 사용할 클래스 로더.
  - getInterfaces() : 구현할 인터페이스.
  - LogPrintHandler(cal) : 부가 기능과 위임 코드를 담은 핸들러.

Example)
 Hello proxiedHello = (Hello)Proxy.newProxyInstance(
     getClass().getClassLoader(), -> 동적으로 생성되는 다이내믹프록시 클래스의 로딩에 사용할 클래스 로더
     new Class[] {Hello.class}, <- 구현할 인터페이스
     new UppercaseHandler(new HelloTarget())); -> 부가기능과 위임코드를 담은 핸들러

* (2) 그런다음 주 업무 클래스의 메서드를 호출하게 되면 프록시 클래스의 invoke 메서드가 호출되어 자신의 보조 업무를 처리하고, 주 업무의 메서드를 호출한다.


* (3) invoke() : 메소드를 실행시킬 대상 오브젝트와 파라미터 목록을 받아서 메소드를 호출한 뒤에 그 결과를 Object  타입으로 돌려준다.

[실제 프록시 및 주 업무(타깃) 처리 순서]

 호출 및 처리 순서 : 클라이언트 ---> 프록시 ---> 타깃

 

AOP 개념은 스프링에 한정되어 사용되는 개념이 아님.

실제 위의 코드는 AOP Proxy의 구현(객체를 생성하고, 값을 주입)하는 것을 순수 JAVA 코드 단에서 처리한 것. (스프링 개념 없이)

스프링을 통해서라면 AOP 는 XML과 어노테이션(Annotation)을 통해서 더 쉽게 구현할 수 있음.

 



출처: http://ooz.co.kr/201?category=818548 [이러쿵저러쿵]

728x90
반응형

'Web Programming > spring' 카테고리의 다른 글

Spring 디자인 패턴  (0) 2018.08.29
Spring 동적 Proxy  (0) 2018.08.29
Spring AOP 란  (0) 2018.08.29
Spring IOC 컨테이너 란  (0) 2018.08.29
Spring DI 란  (0) 2018.08.29
728x90
반응형

4) AOP

 IoC , DI 서비스 추상화와 더불어 스프링의 3대 기반 기술 중의 하나.

 

 AOP는 Aspect Oriented Programming 의 약자인데 그 의미는 무엇인가?

 

 

  4-1) Aspect Oriented Programming의 의미는?

  -> Aspect 를 만드는 프로그램 방법.
  -> Aspect 지향 프로그램.

 

  우리말로 풀이하면 관점 지향 프로그래밍

 

   * 여기서 Aspect는 측면 또는 관점이라는 의미로 볼 수도 있고, 부가적인 업무를 의미하기도 함.

 

 “전통적인 객체지향기술의 설계방법으로는 독립적인 모듈화가 불가능한 트랜잭션 경계설정과 같은 부가 기능을 어떻게 모듈화 할 것인가”
 “트랜잭션(핵심 기능과 부가 기능)의 분리”

 

횡단 관심사와 이에 영향 받는 객체 간의 결합도를 낮추는 것!

 

AOP(관점 지향 프로그래밍)는 왜 사용하는가?

- 주 업무가 아닌 부가적인 업무가 강한 응집력을 가지고 있는 경우, 소스 관리 및 개발 업무 진행의 복잡해지고, 어려워짐.
- 즉 서비스 추상화가 어려워짐. 이러한 문제를 해결하기 위한 프로그래밍 기법으로 OOP(Object Oriented Programming)의 보완적 개념.

 

 - 횡단 관심사와 이에 영향 받는 객체 간 결합도를 낮추는데 목적이 있다. 쉽게 말해 클래스들이 공통으로 갖는 기능이나 절차 등을 하나의 것으로 묶어 빼내어 별도로 관리하려는 목적.

 - 이러한 부가적인 업무의 예로 로그인(Login), 트랜잭션(Transaction), 보안(Security), 캐싱(Caching)과 같은 내부 처리(비지니스, Business) 작업이 있다.

 

AOP는 메인 프로그램의 비즈니스 로직으로부터 2차적 또는 보조 기능들을 고립시키는 프로그램 패러다임(관점 지향 프로그래밍 패러다임)이며, 애플리케이션의 핵심적인 기능에서 부가적인 기능을 분리해서 애스펙트(Aspect)로 정의하고 설계하여 개발하는 방식.

 

위에서도 언급했지만, 스프링 프레임워크에서의 애스펙트(Aspect)란

 - 주업무가 아닌 업무.
 - 보조업무 : 로그, 트랜잭션, 보안처리.

를 의미함.

 

 

 4-2) AOP의 구현이란?

- 주 업무가 아닌 보조적인 업무를 주 업무를 처리하는 코드에서 분리하는 것.

 

 

 4-3) AOP의 장점은 무엇인가?
- 전체 코드 곳곳에 흩어져 있는 다양한 관심 사항이 하나의 장소로 응집.
- 여타 서비스 모듈이 자신의 주요 관심 사항(또는 핵심 기능)에 대한 코드만 포함하고 그 외의 관심 사항은 모두 Aspect로 옮겨지므로 코드가 깔끔해지고, 가독성이 높아짐.

 

참고 : 관점지향프로그래밍(AOP)이란?

링크 : http://ko.wikipedia.org/wiki/%EA%B4%80%EC%A0%90_%EC%A7%80%ED%96%A5_%ED%94%84%EB%A1%9C%EA%B7%B8%EB%9E%98%EB%B0%8D

 

관점지향프로그래밍 패러다임 : 이것은 횡단관심사의 분리를 허용하고, 관점 지향 소프트웨어 개발의 기초를 형성하여 모듈화를 증가시키려 한다. 관점 지향 소프트웨어 개발이 모든 엔지니어링 분야에 관련되는 반면에, 관점 지향 프로그래밍은 소스코드 레벨에서 관심사들의 모듈화를 지원하는 프로그래밍 기술과 툴들을 포함한다.

관점 지향 프로그래밍은 프로그램을 명확한 부분으로 나누는 것을 수반한다. 모든 프로그래밍 패러다임은 이들 관심사들을 구현, 추상화, 구성하는 추상적 개념을 제공하는 분리되고, 독립적인 통로들을 통해 Grouping의 같은 레벨과 관심사들의 캡슐화(Encapsulation)를 지원한다. 그러나 어떤 관심사들은 구현의 이런 형태를 거역하고, 이들이 프로그램 내에서 다중 추상적 개념들에 영향을 끼치기 때문에 횡단관심사(cross-cutting concerns)라고 불린다.

 

 

 4-4) AOP의 시각화

 * 핵심적인 기능에서 부가적인 기능을 분리하여 애스팩트라는 독특한 모듈로 만들어서 설계하고 개발하는 방법.

 

* 독립 애스펙트를 이용한 부가기능의 분리와 모듈화. (애스팩트를 모두 독립시킴) - 위의 그림 참조

 

 

 4-5) AOP는 실제 코드에서 어떻게 처리되는가?

 

 

 기존의 개발 방식은 보조 업무를 담당하는 코드가 주 업무 코드 사이사이에 포함되어 있음.

 

 보조 업무가 주 업무 코드에 포함될 때에는 다음과 같은 일이 발생.
  * 동일한 작업 반복.
  * 보조 업무의 작업 코드가 변경될 시, 해당 보조 업무를 사용하는 모든 주 업무 코드의 소스 수정 필요.
  * 주 업무 코드보다 더 많은 양의 보조 업무 코드 – 특히 DB 객체 생성 및 접속, 예외 처리, DB 닫기 등.

 AOP는 이러한 보조 업무 코드를 주 업무 코드에서 별도로 분리하여 작성하고, 필요할 때에만 도킹(Docking)하여 사용하는 것은 어떨까? 하는 발상에서 나온 개념.

 

 * 여기서 핵심 코드(핵심 관심사)는 Core(Primary) Concern.

 * 부가/보조 업무 코드(횡단 관심사)는 Cross-Cutting Concern.

 

 위의 오른쪽 그림에서 보듯이 주 업무에서 보조 업무를 횡단으로 잘라내었다는 의미로 Cross-Cutting 이라 불림.

 

-------------------------------------------------------------------------------------------------------------------------------

 AOP에 대한 개념과 다룰 범위가 좀 더 넓은데요. 다음 포스팅에서는 스프링 프레임워크에서 실질적으로 AOP를 적용하여 사용하는 기술인 AOP 프록시(AOP Proxy)에 대해 알아보도록 하겠습니다.



출처: http://ooz.co.kr/193?category=818548 [이러쿵저러쿵]

728x90
반응형

'Web Programming > spring' 카테고리의 다른 글

Spring 동적 Proxy  (0) 2018.08.29
Spring AOP Proxy  (0) 2018.08.29
Spring IOC 컨테이너 란  (0) 2018.08.29
Spring DI 란  (0) 2018.08.29
Spring 프레임워크 란  (0) 2018.08.29
728x90
반응형

1. 스프링의 핵심 개념

 - 이어서 계속

 

 

 

3) IoC 컨테이너 (스프링 컨테이너)

 * 제어의 역전 – 외부(컨테이너)에서 제어를 함.

 

> 빈(Bean) : 
 스프링이 제어권을 가지고 직접 만들고 관계를 부여하는 오브젝트.

 

> 빈 팩토리(Bean Factory) : 
 빈(오브젝트)의 생성과 관계 설정 제어를 담당하는 IoC오브젝트. 
 좀 더 확장한 애플리케이션 컨텍스트(application context)를 주로 사용.

 

> 애플리케이션 컨텍스트: (IoC 컨테이너 or  스프링 컨테이너)
 DI를 위한 빈 팩토리에 엔터프라이즈 애플리케이션을 개발하는 데 필요한 여러 가지 컨테이너 기능을 추가한 것.

 

> 설정정보/설정 메타정보
 구성정보 or 형상정보 (XML)

 

> 스프링 컨테이너(IoC 컨테이너) : 
 IoC 방식으로 빈을 관리한다는 의미에서 애플리케이션 컨텍스트나 빈 팩토리를 의미.

 

IoC컨테이너는 다른 용어로 빈 팩토리(Bean Factory), 애플리케이션 컨텍스트(Application Context) 라고도 불림.
스프링의 IoC 컨테이너는 일반적으로 애플르케이션 컨텍스트를 말함.

 

* 빈 팩토리를 애플리케이션 컨텍스트 또는 IoC컨테이너라 말하기도 하지만, 사실 애플리케이션 컨텍스트는 빈을 좀 더 확장한 개념.
* 애플리케이션 컨텍스트는 그 자체로 IoC와 DI를 위한 빈 팩토리(Bean Factory)이면서 그 이상의 기능을 가짐.
* 빈팩토리와 어플리케이션컨텍스트는 각각 BeanFactory, ApplicationContext 두 개의 인터페이스로 정의
* ApplicationContext 인터페이스는 BeanFactory 인터페이스를 상속한 서브인터페이스.
* 실제로 스프링 컨테이너 또는 IoC 컨테이너라고 말하는 것은 바로 이 ApplicationContext 인터페이스를 구현한 클래스의 오브젝트.
* 컨테이너가 본격적인 IoC 컨테이너로서 동작하려면 POJO클래스와 설정 메타정보가 필요.

   (스프링 애플리케이션 : POJO 클래스와 설정 메타정보를 이용해 IoC 컨테이너가 만들어주는 오브젝트의 조합.)

 

 * IoC 컨테이너
 어떠한 객체의 명세서를 작성하고, 스프링 라이브러리는 해당 명세대로 객체를 생성. 생성된 객체(그리고 디펜던시)들을 보관하는 공간을 의미.

 

 

* EJB : Enterprise Java Bean (엔터프라이즈 자바빈) – 효율적으로 서버 관리를 해주고, 또 프로그램 관련 문제들을 알아서 처리해준다는 개념.

  (연결 관계가 복잡하고, 무겁고, 독립적이지 못하다)
* DL : Dependency Lookup 

* DI : Dependency Injection

 

DL(Dependecy Lookup) - JNDI 같은 저장소에 의하여 관리되고 있는 bean을 개발자들이 직접 컨테이너(Container)에서 제공하는 API를 이용하여 lookup하는 것을 말함. 따라서 container와의 종속성이 생김. (JNDI 컨테이너에 의존성이 강하다. )

 오브젝트간에 디커플링(decoupling)을 해주는 면에서 장점이 있지만 이렇게 만들어진 오브젝트는 컨테이너 밖에서 실행 할 수 없고 JNDI외의 방법을 사용할 경우 JNDI관련 코드를 오브젝트내에 일일히 변경해 줘야 하며 테스트하기 매우 어렵고 코드 양이 매우 증가하고 매번 Casting해야 하고 NamingException같은 checked exception을 처리하기 위해서 exception처리구조가 매우 복잡해지는 단점이 있음.

 EJB container, Spring container 에서 지원. 

 

DI (Dependecy Injection) – 각 class 사이의 의존관계를 빈 설정 정보를 바탕으로 container가 자동적으로 연결해 주는 것을 말함. 따라서 lookup과 관련된 코드들이 오브젝트 내에서 완전히 사라지고 컨테이너에 의존적이지 않은 코드를 작성할 수 있음.

 단지 빈 설정 파일에서 의존관계가 필요하다는 정보를 추가하면 됨.
1) Setter Injection – 클래스 사이의 의존관계를 연결시키기 위하여 setter 메소드를 이용하는 방법. property tag 사용. 
2) Constructor Injection – 클래스 사이의 의존관계를 연결시키기 위하여 constructor를 이용하는 방법. constructor-arg tag 사용. 
3) Method Injection – 싱글톤(Singleton) 인스턴스와 non singleton 인스턴스의 의존관계를 연결시킬 필요가 있을 때 사용하는 방법.

 

 

참고) JNDI (Java Naming and Directory Interface)

* 엔터프라이즈 애플리케이션을 위한 네이밍과 디렉토리 서비스 표준 인터페이스
* Java 소프트웨어 클라이언트가 이름(Name)을 이용하여 데이터 및 객체를 찾을 수 있도록 도와주는 디렉토리 서비스에 대한 Java API.

[Naming Service 구조]

 

Naming Service (네이밍 서비스)
 * Java Naming and Directory Interface(JNDI) API를 이용하여 자원(Resource)을 찾을 수 있도록 도와주는 서비스. Naming 서비스를 지원하는 Naming 서버에 자원을 등록하여 다른 어플리케이션에서 사용할 수 있도록 공개하고, Naming 서버에 등록되어 있는 자원을 찾아와서 이용할 수 있게 함.

 * DNS서버 같은 개념.

 

JNDI(Java Naming and Directory Interface)
 - 디렉토리 서비스에서 제공하는 데이터 및 객체를 발견하고 참고하기 위한 자바 API.
 - J2EE 플랫폼의 일부.
 - 여러 대의 서버 간에 JNDI를 이용하여 객체를 등록, 참조하여 이용.
 - javax.naming 패키지 안에 존재.
 - 여러 웹 서버(톰캣, 웹로직, 제우스 등)에서 사용.
 - 기본 네임스페이스는 java:com/env.

 

 



출처: http://ooz.co.kr/178?category=818548 [이러쿵저러쿵]

728x90
반응형

'Web Programming > spring' 카테고리의 다른 글

Spring AOP Proxy  (0) 2018.08.29
Spring AOP 란  (0) 2018.08.29
Spring DI 란  (0) 2018.08.29
Spring 프레임워크 란  (0) 2018.08.29
Spring MVC 패턴 / 프로젝트 생성 / 파일 구조  (0) 2018.08.29
728x90
반응형

1. 스프링의 핵심 개념

 * DI

 * IoC

 * AOP & AOP Proxy

 * AOP in Spring

 

 1) 주요 구성 요소 

 * IoC / DI

 * AOP

 * PSA

 

 

 

 

- 용어 설명 -

* Plain Old Java Object 혹은 POJO는 처음에 javax.ejb 인터페이스를 상속받지 않은, 무거운 EJB와는 반대로 경량의 자바 객체를 지칭하는 용어로 소개. 즉, POJO라는 이름은 특별하지도 않고, 특히 Enterprise JavaBean이 아닌 자바 객체를 강조하는 의미로 사용.

 이 이름은 Martin Fowler, Rebecca Parsons와 Josh MacKenzie에 의해 2000년 9월에 만들어졌으며, 프레임워크에 종속된 복잡한 객체에 반대되는 간단한 객체를 설명하기 위한 용어의 필요성이 많아짐에 따라 POJO라는 이름이 점점 널리 쓰여짐.

 POJO 대표적인 예로, JavaBean을 들 수 있는데, JavaBean은 기본 생성자와 멤버 필드에 접근할 수 있는 getter/setter 메소드를 가진 serializable(직렬화가 가능한)한 객체를 의미. POJO를 이용한 디자인이 널리 쓰임에 따라 POJO를 기본으로 하는 스프링이나 하이버네이트와 같은 프레임워크에서도 생겨남. 요즘에는 POJO는 (EJB 뿐만 아니라) 별도로 종속되지 않는 자바 객체를 통칭하여 의미한다.

 

* PSA (Portable Service Abstractions) – (쉬운) 서비스 추상화
 성격이 비슷한 여러 종류의 기술을 추상화하고 이를 일관된 방법으로 사용할 수 있도록 지원.
 트랜잭션 서비스 추상화 : 여러 가지의 DB를 사용한다고 하면 Global Transaction 방식을 사용.
 자바는 JDBC 외에 이런 글로벌 트랜잭션을 지원하는 트랜잭션 매니져를 지원하기 위한 API인 JTA(Java Transaction Api)를 제공.
 높은 응집도와 낮은 결합도를 준수.

 

 

 2) DI (Dependency Injection, 의존성 주입)

  DI는 스프링(Sping)을 통해서 특별히 생겨난 용어는 아님. 단 DI를 잘 지원해주는게 스프링.

 

* 일체형

 

 - Composition : HAS-A 관계

 - A가 B를 생성자에서 생성하는 관계 .

 

 

 

 

* 분리 / 도킹(부착) 형

 - Association 관계

 - A객체가 다른 녀석이 만든 B 객체를 사용. 

 

 

예제 설명

A를 스마트폰, B를 배터리리라 하면,

일체형 스마트폰 (아이폰)은 바로 전원을 켜도 되지만,

배터리 탈부착 형태의 스마트폰 (갤럭시S)은 여기서는 배터리를 넣고, 전원을 넣어야 함.

 

일체형은 A라는 객체의 내부 프로세스에 대해 신경 쓸 필요가 없으며, 분리형은 A와 B를 개별적으로 세팅해 주어야 함. 단, 분리형은 내가 원하는 것(다른 배터리)으로 바꾸어 부착할 수 있음. 이것을 DI의 개념이라 보면 됨.

 

 

위의 예제 처럼 분리/도킹(부착) 형으로 개발을 하게 되면 각 객체(또는 애플리케이션) 간의 결합도를 낮출 수 있으며, DI를 사용하는 목적이 이러한 결합도를 낮추기 위함.

 

 

 2-1) DI의 종류

  * Setter Injection (세터 주입)

  * Construction Injection (생성자 주입)

 

 

Setter Injection

 B b = new B();

 A a = new A();

 a.setB(b);

 

 

Construction Injection

 B b = new B();

 A a = new A(b);

 

 

 위의 코드는 JAVA 개발자라면 친숙한 개념으로 DI는 JAVA에서도 많이 사용해 왔던 개념. (객체 지향 프로그래밍(OOP)에 있던 개념)
 단지, 스프링에서는 이러한 일련의 과정을 (동적으로) 자동화 함.


 

 2-2) 스프링에서의 DI

 * 명세서에 따라서 자동적으로 부품을 활용하여 제품을 조립 => 스프링

 

 * 일체형 프로그램과는 반대로 제품을 생성.

 * 즉, 작은 부품부터 시작하여 큰 부품으로 이동하며 조립.
 => Inversion of Control (IoC)

 

기본적인 완제품 제작 순서와는 다르게 작은 부품부터 큰 부품으로, 제품을 만드는 순서가 역순 (Inversion of Control).
그래서 IoC라는 이름이 붙었으며, 이러한 일련의 작업을 스프링은 컨테이너라는 곳에 담아서 처리하여 스프링을 IoC컨테이너라 함.

스프링은 완성품을 만드는 것보다 부품을 모아서 조립하는 것을 도와줌. 즉, 이러한 DI 구조를 개발자가 좀 더 쉽고, 간편하게 사용할 수 있도록 지원해 주는 프레임워크 중의 하나가 스프링.


 

 스프링에서의 DI의 의미

부품들을 생성하고제품을 조립해주는 공정과정을 대신해 주는 라이브러리 (역할자)

 

 * 개발 핵심 처리 루틴의 수정 없이 제품(객체)를 다른 제품(객체)로 쉽게 대체하여 생성 가능하도록 하는 역할을 함.

 * 명세서에 따라서 자동적으로 부품을 활용하여 제품을 조립.

 * 생성하기 원하는 객체를 명세서(XML)에 기술하고, 그 부품과 의존성(Dependency)들을 보관하는 일을 처리. 그러한 데이터를 보관하는 공간을 컨테이너라 함. (IoC 컨테이너)

 

제품 

스프링 

 주문서

 설정파일(XML) 

 일반적은 순서의 공정

 역방향 조립 

 

 

2-3) DI 구현

 

 객체의 생성과 도킹에 대한 내용이 소스 코드 상에 있는 것이 아닌 별도의 텍스트 파일(XML 설정 파일)에 분리하여 존재. 
 (JAVA소스 컴파일 없이 XML 변경만으로 내용 변경 가능)

 

JAVA(DI) : Property 항목은 실제 값을 record에 바로 주입하는 것이 아닌 setRecord() 함수를 호출하여 주입함.

 • JAVA (DI)

Record record = new SprRecord();

RecordView view = new SprRecordView();

view.setRecord(record); // Injection

view.input();

view.print();

 

 

XML (스프링 DI) : 객체 생성 시, 패키지명을 포함한 풀 클래스 네임 작성.

XML에 작성된 명세서를 보고, IoC컨테이너가 각 객체를 생성하고, 값을 주입해줌.

여기서 ApplicationContext 가 IoC컨테이너 역할을 함.

• XML (스프링 DI) config.xml

<bean id=“record” class=“di.SprRecord”></bean> // 빈 객체 생

<bean id=“view” class=“di.SprRecordView”> // 빈 객체 생성

  <property name=“record” ref=“record”></property> // setRecord() 호출 

</bean>

 • JAVA

// XML을 파싱하여 컨테이너에 담는 작업

ApplicationContext ctx = new ClassPathXmlApplicationContext(“config.xml”);

RecordView = (RecordView) ctx.getBean(“view”);

 

 

 * XML을 활용(스프링 DI)하는 경우는 VIEW에 대한 객체만을 요청했을 뿐, 실제 내부적인 사항은 JAVA코드 상에 드러나지 않음.
 * 새로운 클래스의 bean객체를 만들어 XML에 주입만 시켜줘도, 기존 소스 변경 없이 새로운 형태의 객체 적용이 가능함.

 

 

2-4) XML (Bean) Sample

 

* 빈(Bean) 객체는 반드시 클래스를 사용. 인터페이스나 추상클래스는 객체 생성이 불가능함.
* 빈 객체 생성, 객체 초기화, 객체 값(또는 레퍼런스) 주입.

 

XML (스프링 DI) config.xml

 

1)
<bean id=“record” name=“r1,r2 r3;r4” class=“di.SprRecord”>
    <property name=“kor” value=“20”></property>
</bean>

2)

<bean id=“record” name=“r1,r2 r3;r4” class=“di.SprRecord”>
    <constructor-arg value=“20”></constructor-arg>
</bean>

3)

<bean id=“record” name=“r1,r2 r3;r4” class=“di.SprRecord”>
    <constructor-arg name=“kor” value=“20”></constructor-arg>
</bean>

4)

<bean id=“record” ” name=“r1,r2 r3;r4” class=“di.SprRecord”
    p:kor=“50” p:eng=“60” p:math=“70”>

5)

<bean id=“view” class=”di.SprRecordView”>
    <property name=“record” ref=“record”></property>
</bean>
 

id : 빈 객체 고유 이름 (접근 가능자)

name : 객체의 이름(별칭)

class : 생성할 클래스

constructor-arg : 초기값 설정 (생성자 함수 사용)

property : 초기값 설정 (Setter함수 사용)

 

1) 이름이 record인 빈 객체 생성 / 별명 4개 : r1,r2,r3,r4 / SprReocrd 클래스 객체 생성.

    초기값으로 kor 라는 프로퍼티에 20값 대입 (set함수가 존재해야 위와 같은 프로퍼티 설정이 가능).
2) 이름이 record인 빈 객체 생성 / 생성자(인자가 하나인)를 통해서 값 대입 & 생성.
3) 생성자 중에서 kor 값을 입력받는 생성자를 통해서 20값 대입하고, 생성.
4) 3개의 인자를 받는 생성자를 통해 kor = 50, eng = 60, math = 70 대입 & 생성.
5) 생성된 record 객체를 set함수를 통해 프로퍼티에 저장하고 SprRecordView를 생성.

 

참고로 값을 대입하는 경우에는 value, 참조(레퍼런스)를 대입하는 경우에는 ref 를 사용.



출처: http://ooz.co.kr/175 [이러쿵저러쿵]

728x90
반응형

'Web Programming > spring' 카테고리의 다른 글

Spring AOP 란  (0) 2018.08.29
Spring IOC 컨테이너 란  (0) 2018.08.29
Spring 프레임워크 란  (0) 2018.08.29
Spring MVC 패턴 / 프로젝트 생성 / 파일 구조  (0) 2018.08.29
web.xml 설정추가  (0) 2013.09.24
728x90
반응형

1. 스프링의 이해

 1.1) 스프링 정의

   - 간단히 스프링이라 지칭하지만 정확하게는 스프링 프레임워크 (Spring Framework) 라고 하는 것이 정확한 표현.'

 

  * 자바(JAVA) 플랫폼을 위한 오픈소스(Open Source) 애플리케이션 프레임워크(Framework)
  * 자바 엔터프라이즈 개발을 편하게 해주는 오픈 소스 경량급 애플리케이션 프레임워크
  * 자바 개발을 위한 프레임워크로 종속 객체를 생성해주고,  조립해주는 도구
  * 자바로 된 프레임워크로 자바SE로 된 자바 객체(POJO)를 자바EE에 의존적이지 않게 연결해주는 역할.

 

 

 

 - POJO 란 Plain Old Java Object 의 약자로 특별한 뜻을 담고 있는 용어는 아니며, 단순히 평범한 자바빈즈(Javabeans) 객체를 의미함.

 

 

- 참고 -

 

JAVA : JAVA 개발 언어

Open Source : 소프트웨어 혹은 하드웨어의 제작자의 권리를 지키면서 원시 코드를 누구나 열람할 수 있도록 한 소프트웨어 혹은 오픈 소스 라이선스에 준하는 모든 통칭을 일컫는다. (소스가 공개되어 여러 개발자가 플랫폼을 함께 개발, 구축, 보완해 나가는 시스템. )

Framework : 개발할 때 설계 기본이 되는 뼈대나 구조 / 환경 (문제 영역을 해결한 재사용, 확장 가능한 라이브러리.)

POJO : http://ko.wikipedia.org/wiki/Plain_Old_Java_Object

 

 

 1.2) 스프링 특징

 * 크기와 부하의 측면에서 경량.

 * 제어 역행(IoC)이라는 기술을 통해 애플리케이션의 느슨한 결합을 도모.

 * 관점지향(AOP) 프로그래밍을 위한 풍부한 지원을 함.

 * 애플리케이션 객체의 생명 주기와 설정을 포함하고 관리한다는 점에서 일종의 컨테이너(Container)라고 할 수 있음.

 * 간단한 컴포넌트로 복잡한 애플리케이션을 구성하고 설정할 수 있음.

 

 

- 스프링의 특징을 좀 더 상세히 말하자면 -

1) 경량 컨테이너로서 자바 객체를 직접 관리.

    각각의 객체 생성, 소멸과 같은 라이프 사이클을 관리하며 스프링으로부터 필요한 객체를 얻어올 수 있다.
2) 스프링은 POJO(Plain Old Java Object) 방식의 프레임워크.

   일반적인 J2EE 프레임워크에 비해 구현을 위해 특정한 인터페이스를 구현하거나 상속을 받을 필요가 없어 기존에 존재하는 라이브러리

   등을 지원하기에 용이하고 객체가 가볍다.
3) 스프링은 제어 반전(IoC : Inversion of Control)을 지원.

   컨트롤의 제어권이 사용자가 아니라 프레임워크에 있어서 필요에 따라 스프링에서 사용자의 코드를 호출한다.
4) 스프링은 의존성 주입(DI : Dependency Injection)을 지원

   각각의 계층이나 서비스들 간에 의존성이 존재할 경우 프레임워크가 서로 연결시켜준다.
5) 스프링은 관점 지향 프로그래밍(AOP : Aspect-Oriented Programming)을 지원

   따라서 트랜잭션이나 로깅, 보안과 같이 여러 모듈에서 공통적으로 사용하는 기능의 경우 해당 기능을 분리하여 관리할 수 있다.
6) 스프링은 영속성과 관련된 다양한 서비스를 지원

   iBatis나 Hibernate 등 이미 완성도가 높은 데이터베이스 처리 라이브러리와 연결할 수 있는 인터페이스를 제공한다.
7) 스프링은 확장성이 높음.

   스프링 프레임워크에 통합하기 위해 간단하게 기존 라이브러리를 감싸는 정도로 스프링에서 사용이 가능하기 때문에 수많은 라이브러리

   가 이미 스프링에서 지원되고 있고 스프링에서 사용되는 라이브러리를 별도로 분리하기도 용이하다.

 

출처 : http://ko.wikipedia.org/wiki/%EC%8A%A4%ED%94%84%EB%A7%81_%ED%94%84%EB%A0%88%EC%9E%84%EC%9B%8C%ED%81%AC

 

  - 또다른 특징 -

 * 동적(Dynamic) 웹 사이트 개발을 위한 프레임워크

 * 대한민국 전자정부 표준 프레임워크의 기반 기술

 

 

 

 1.3) 스프링 역사

* Rod Johnson 이 2002년 출판한 자신의 저서 Expert One-on-One J2EE Design and Development에 선보인 코드가 시초.

 * 이 프레임워크는 2003년 6월 최초 아파치 2.0 라이선스로 공개.

* 2004년 3월에 1.0 버전이 릴리즈 되고, 2011년 12월에 현재 최신 버전인 3.1 버전이 공개됨.

 

참고) 로드 존슨이 자신의 JAVA 개발 경험과 노하우를 기반으로 출판한 책에 샘플 프레임워크를 만들어서 저서에 실었는데, 이것이 차후 스프링이란 자바 표준 프레임워크로 발전하게 됨.



출처: http://ooz.co.kr/170 [이러쿵저러쿵]

728x90
반응형

'Web Programming > spring' 카테고리의 다른 글

Spring IOC 컨테이너 란  (0) 2018.08.29
Spring DI 란  (0) 2018.08.29
Spring MVC 패턴 / 프로젝트 생성 / 파일 구조  (0) 2018.08.29
web.xml 설정추가  (0) 2013.09.24
spring-security xml 설정  (0) 2013.09.24

+ Recent posts