Once more into the fray

Reference

Spring의 시작, 프레임워크의 구성요소와 동작원리
스프링 프레임워크 핵심

POJO
스프링 프레임워크 1 - POJO에 대하여
POJO vs JavaBeans
Understanding : POJO

IoC/DI
스프링 프레임워크 2 - 컨테이너와 IoC
Spring 프레임워크 소개와 IoC 및 Spring IoC의 개념
세 가지 DI 컨테이너로 향하는 저녁 산책
스프링이 도대체 뭐란 말인가?

핵심 개념들

• 스프링 프레임워크를 공부하면서 자주 언급되고 매우 중요하다고 생각하는 용어들을 정리했습니다
• 아직 많은 것을 알지 못하기 때문에 자세하고 정확한 내용은 제가 참조한 사이트나 따로 검색 또는 책을 통해 알아보는 것을 권장드립니다.

POJO

이해가 어려우신 분들은 간략히,

• 스프링 프레임워크를 사용하면 POJO로 애플리케이션을 만들고 엔터프라이즈 서비스를 비침투적으로 POJO에 적용할 수 있다
• 모든 JavaBeans는 POJO 이지만, 모든 POJO는 JavaBeans가 아니다

이 정도만 숙지하고 넘어가셔도 상관 없을 것 같습니다.

✔ Plain Old Java Object : (직역) 평범한 옛날 자바 객체

더 자세한 내용은 다른 포스트에서 다루겠지만, 간략히 스프링 공식 홈페이지에서는 POJO를 다음과 같이 소개합니다.

By using plain old Java objects, your code is much more simplified, which lends to better testing, flexibility, and ability to change technical decisions at future stages based on knowledge and shifting requirements.

POJO를 사용함으로써,

• 코드가 간결해져서 테스트하기 편해지고 (비즈니스 로직과 특정 환결/로우 레벨 종속적인 코드를 분리함)
  쉽게 말해 인터페이스, 상속이 없는 것
• 유연해서 객체지향적 설계의 자유료운 사용이 가능

POJO 기반의 프레임워크 == 스프링 프레임워크

많은 POJO 프레임워크가 있고 하이버네이트와 스프링이 대표적이라고 할 수 있습니다. (이 둘의 차이점은 굳이 자세히 알아보지는 않겠습니다.) 스프링 프레임워크가 많은 POJO 프레임워크 제품 중 하나라는 정도로 알고 넘어가셔도 좋습니다.

진정한 POJO 프로그래밍

자바의 객체지향적인 특징을 살려 비즈니스 로직에 충실한 개발이 가능하도록 하는 것이 진정한 POJO 프로그래밍이라고 할 수 있습니다. 마치 자바를 처음 배울 때 흔히 하는 실수로, 개발은 자바로 하지만 실제로는 C 언어를 배우며 익숙해진 절차지향 방식으로 구현하는 것을 생각하시면 되겠습니다. 따라서 POJO 프레임워크 제품을 사용한다고 해서 자동으로 POJO 형식의 개발을 하고 있다고 할 수 없음을 인지하고 계셔야 합니다.

• 객체지향적인 설계원칙에 충실하도록 개발되어 있는지
• 테스트 코드 개발의 용이성이나 테스트 코드를 잘 작성했는지

를 잘 확인하시면서 POJO 프로그래밍의 장점을 잘 살려 스프링 프레임워크의 활용도를 극대화하려고 노력해야 할 것 같습니다.

IoC / DI

개인적으로 재밌었던 표현이라 그대로 참조한 블로그스프링이 도대체 뭐란 말인가?(꼭 읽어보면 좋을 것 같습니다)의 표현을 그대로 인용하자면, 간략하게 이 둘을 “대신 해줌(IoC)” 과 “미리 찜해 놓음(DI)” 이라고 설명하였습니다.
정신 나간듯 언제 사용될 지도 모르는 코드를 쳐대면서(IoC) 동시에 사용하고 있는 코드가 뭔지도 모르면서 일단 갖다 쓰는(DI) 획기적이고 진보적인 프로그래밍 작성 방식 으로 IoC/DI의 개념을 표현하였고 어려우시면 이 정도로 이해하고 일단 넘어가시는 것도 좋을 것 같습니다.

✔ Inversion of Control : 제어의 역전

• 제어권(Control)

  자바 객체의 생성, 생명주기 관리, 객체간의 의존관계를 연결시키는 등의 행위에 대한 권한

• 객체에 대한 제어 권한이 바뀌는 것 즉, 제어 권한을 다른 대상에게 위임하는 것이라는 의미 (개발자 -> 컨테이너)

• 프레임워크에서 개발자는 필요한 부분을 개발해서 “조립”하는 방식을 취하는데, 이렇게 조립된 코드의 최종 호출은 개발자에 의해서 제어되는 것이 아니라 프레임워크 내부 동작 원리에 따라 이루어짐. 이를 제어의 역전 이라고 표현

• 스프링 프레임워크에서 지원하는 IoC Container는 POJO의 생명주기를 관리, 생성된 인스턴트들에게 추가적인 기능들을 제공
  cf) 라이브러리 vs 프레임워크 –> IoC의 개념이 적용되었나의 차이

✔ Dependency Injection : 의존성 주입

• 의존성(Dependency)

  현재 객체가 다른 객체와 상호작용(참조)하고 있다면, 다른 객체들을 현재 객체의 의존 이라고 표현

• DI는 스프링 프레임워크에서 지원하는 IoC의 형태

• DI는 클래스 사이의 의존관계를 빈 설정 정보를 바탕으로 컨테이너가 자동적으로 연결

  예시)

  Ioc/DI 가 적용되지 않은 경우

package kr.co.study;

public class Foo
{
    private Bar bar;

    public Foo(){
        bar = new SubBar();	//Bar 인터페이스를 구현하는 구체적인 클래스 SubBar로 초기화
    }
}

​ Ioc/DI 가 적용되지 않은 경우

//Container
<beans>
	<bean id="bar" class="kr.co.study.SubBar">
    <bean id="foo" class="kr.co.study.Foo">
        <property name="bar" ref="bar"/>		<!-- 사용할 객체들을 컨테이너에 등록 -->
    </bean>
</beans>

//application code
package kr.co.study;

public class Foo
{
    private Bar bar;

    public void setBar(Bar bar){	//사용할 객체를 매겨변수로 받아와 동적으로 의존관계를 설정
        this.bar = bar;				//Bar 인터페이스를 구현하는 구체적인 클래스 이름이 등장하지 않음
    }
}

• 마틴 파울러가 그의 저서인 ‘Inversion of Control Containers and the Dependency Injection pattern’에서 세가지 DI 패턴을 제시
  • setter() 메소드를 이용한 의존성 삽입(Setter Injection)
  • 생성자를 이용한 의존성 삽입 (Constructor Injection)
  • 초기화 인터페이스를 이용한 의존성 삽입(Interface Injection)

스프링 프레임워크 모듈

위 그림에 나와있듯이 스프링 프레임워크는 약 20개의 모듈들로 이루어져 있습니다.

• Data Access/Integration; Web; AOP; Aspects; Instrumentation; Messaging; Core Container; and Test;

이처럼 스프링은 웹 애플리케이션 개발, 데이터베이스 접근, 트랜잭션 관리, 단위 및 통합 테스트 생성 등등 엔터프라이즈 애플리케이션 개발의 모든 측면을 지원하고 이렇게 다양한 기능 중 우리는 필요한 것만 선택적으로 사용하면 됩니다.

만약 개발하고 있는 애플리케이션에서 스프링의 DI 기능[^1]을 사용하려면 Core Container 모듈 그룹에 속한 Spring-Core나 Spring-Beans 모듈을 선택해 사용하면 됩니다.

스프링 프레임워크 모듈 간 상호의존성

• Core Container 그룹이 스프링 프레임워크의 중심
• AOP 및 Instrumentation 그룹에 포함된 모듈도 이를 의존하는 다른 모듈이 많기에 중요도가 높음

지금은 이해가 잘 안되지만 앞으로 각각의 모듈들에 대해 자세히 알아볼 예정입니다.

다음 포스팅에서는 각각의 모듈들을 알아가기 전에 꼭 알아둬야하는 개념들을 가볍게 집고 넘어가겠습니다.

• 제어의 역적(IoC); 의존성 주입(DI); 관전 지향 프로그래밍(AOP); Model View Control(MVC);

[^1]: DI 기능에 대해서는 다음에 따로 포스트할 예정(포스팅 하면 수정!!)

Related Posts

본 문서는 IHIS 연구소의 ‘HL7 C-CDA 교육’ pdf 문서를 기반으로 작성 되었습니다.

Pre-Consolidation context

CDA 통합 이전

컴퓨터와 인터넷이 보편화 되고 사람들의 기대수명이 높아지면서 ICT(Information and Communication System) 기술을 보건의료 영역에 적용하려는 움직임이 시작 되었습니다.
하지만 병원과 기관마다 서로 다른 소프트웨어를 사용하기 때문에 정보 교환 또는 호환이 어려운 문제점이 있었습니다. 이를 해결하고자 HITSP, HL7, IHE, Health Story 등의 여러 기업 및 기관들이 표준화된 CDA(Clinical Document Architecture)를 규정하고, 많은 사람들이 자신들의 표준을 사용하게 하기 위해 CDA Implementation Guide(CDA IG) 를 배포하였습니다.
각각의 표준은 비슷하지만 조금씩은 차이가 있었기 때문에 진정한 표준이 되지 못하고 다람쥐 쳇바퀴 돌 듯 이 문서들 간의 교환 및 교환의 문제가 발생하였습니다.

Consolidated CDA

2012년 the Office of the National Coordinator for Health Information Technology(ONC) 에서 이러한 문제점을 해결하고자 Consolidated CDA 라는 통일된 표준 을 제시하였다고 위키피디아[^1]에 적혀있습니다. 저는 대중적으로 많이 사용하는 HL7 기관에서 2011년 12월에 발표한 ‘A draft Implementation Guide for CDA Release 2.0, Consolidated CDA Templates’[^2]를 기반으로 다룰 것 입니다.

C-CDA IG 는 아래와 같은 의료 문서를 포함합니다(year released)

• Consultation Note(2008)
• Discharge Summary(2009)
• Imaging Integration and DICOM Diagnostic Imaging Reports(DIR)(2009)
• History and Physical(H&P)(2008)
• Operative Note(2009)
• Progress Note(2010)
• Procedure Note(2010)
• Unstructured documents(2010)

C-CDA IG Navigation

Consolidated CDA 작성 방법에 대한 자세한 정보는 공식 홈페이지를 참조하면 될 것 같습니다.
HL7 Implementation Guide for CDA Release 2:IHE Health Story Consolidation, Release 1.1 - US Realm

[^1]: Consolidated Clinical Document Architecture 탭에 있음
[^2]: 초안의 사본은 HL7 웹 사이트를 가면 쉽게 찾을 수 있습니다.