관리 메뉴

나만의공간

스프링 주요 개념 용어 1 - Beans 와 POJO 본문

IT/Spring

스프링 주요 개념 용어 1 - Beans 와 POJO

밥알이 2014. 6. 9. 17:18

아래 내용은 해당 블로그에서 가져왔습니다.

http://blog.naver.com/acatholic/90176619710


1. bean, java beans

: 그냥 어플리케이션 컴포넌트를 가리킴(그냥 클래스나 패키지 같은 모듈. 부품들)

이 말이 sun에서 발표한 java beans 스펙을 준수해야 한다는 건 아님.

 

POJO 타입이면 어떤 것이든 스프링 컴포넌트가 될 수 있음.

(A Spring Component can be any type of POJO)

 

 

2. POJO(plain-old java object)

예전 midp 에서 j2se 를 지칭하던 용어인 pure java 정도로 이해하면 될 듯함.

 

다른 사람들 블로그에서 본 바로는 

평범한 자바객체로 코딩하고 extends 나 implements 하여

어딘가에 종속되거나 pure java 의 클래스들을 침해(invasive)하지 않도록 하는 것이라는 의견도 있음.

pure java 가 아닌 특정 컴포넌트를 extends 나 implements 하지 않아도 되도록 하는것이 POJO 개념에 부합한다는 얘기를 하는 듯 함.

 

 

 

 

아래는 http://blog.daum.net/aqua0405/5558386 에 나와 있는 내용임.

 1. POJO - Plain Old Java Object


- 평범한 java Object,즉 자바개발자가 마음대로 정의 할수 있는 객체라는 뜻이다.
- EJB 컨테이너에 의존 하는 객체 처럼 복잡하지 않고 개발자가 쓰기 편한 간단한 Object를 만들어 쓰자는
  간단한 Object의 개념이다.
- Object를 간단히 수퍼클래스로 둔 보통의 평범의 그자체 순수 자바클래스 라고 봐도 괜찮다.

2. POJO의 필수요소

- light-weight(possibly) : 가볍게
- fiexible : 유연성
- simple : 간단 명료
- supported by separate opional components such as hiberate or spring

- 즉, Spring, Hiberate, Ibatis 등에서 객체를 가볍게, 간단히 유연하게 
   어떤 Object에 대해 추상화 할수있는 객체를 만들어야한다.
 (ex. DTD의 쓰임)

 

 

 

아래는 http://blog.naver.com/thtlsgkrtod/40055742326 에서 가져온 내용임.

 POJO (Plain Old java Object) 를 해석하면 평범 자바 오브젝트라고 한다. 

POJO를 이해 하기 전  POJO라는 단어가 만들어진 역사적 배경을 살펴볼 필요가 잇다. POJO는 마틴 파울러가  2000년 가을에 열렸던 어느 컨퍼런스의 발표를 준비하면서 처음 만들어낸 말이다. 마틴 파울러는 EJB(Enterprise JavaBean)보다는 단순한 자바 오브젝트에 도메인 로직을 넣어 사용하는 것이 여러가지 장점이 있는데도 왜 사람들이 그 EJB가 아닌 '평범한자바 오브젝트'를 사용하기를 꺼려 하는지에 대해 의문을 가졌다. 그리고 그는 단순한 오브젝트에는 EJB와 같은 그럴듯한 이름이 없어어서 그 사용을 주저하는 것이라고 결론 내렸다. 
  그래서 만든 단어가 POJO라는 용어인 것이다. POJO기반의 기술을 사용한다고 말하면 왠지 첨단 기술을 사용하는 앞선 개발자인 듯한 인상을 주기 때문인다.

POJO기반의 프로그래밍 기술이 EJB의 강력한 대안으로 등장했고 ,POJO 기반 프레임워크 ,POJO 애플리케이션을 위한 플랫폼 등이 점점 인기를 끌게 되었고, 결국 POJO가 배제하려고 했던 EJB는 POJO기반의 기술에 밀려 이제 레거시 기술로 사라질 위기에 처했다. 그렇다면 단지 EJB를 사용하지 않으면 모두 POJO라고 할 수 있을까? 그렇지 않다. POJO프로그래밍이라는 개념은 단지 "EJB가 아닌 자바"이상의 특징을 가지고 있는 프로그래밍 모델이다. POJO기반의 개발은 생각보다 단순하지 않다.
  POJO를 좀더 이해하려면 EJB의 장단점을 함께 이해해야 한다. 그것은 POJO 프로그래밍이 다시 EJB시대이전으로 돌아 가자는 것이 아니고 ,EJB를 넘어 그보다 더 앞으로 나아가자는 것이기 때문이다. 
EJB를 사용하지 말고 POJO를 쓰자는 것은  EJB이전의 방식으로 돌아 가는 것을 의미한다면 또 다른 문제가 발생 할 수 밖에 없다. 여전히 복잡한 로우레벨의 API를 이용해 코드를 작성해야 하고, 많은 기술적인 문제를 애플리케이션 코드에 그대로 노출시켜 개발해야 한다면 기껏 POJO로의 복귀 덕분에 얻는 많은 장점들을 놓칠 수 밖에 없다. 

  그래서 등장한 것이 POJO 기반의 프레임워크이다. POJO프레임워크는 POJO를 이용한 애플리케이션 개발이 가진 특징과 장점을 그대로 살리면서 EJB에서 제공하는 엔터프라이즈 서비스와 기술을 그대로 사용할 수 있도록 도와주느 프레임워크이다. 나아가 이는 기존의 EJB에서보다 훨씬 더 세련되고 나은 방법이다. 데표적인 프레임웤 스프링 하이버네이트~!

참고로 스프링은 엔터프라이즈 서비스들을 POJO기반으로 만든 비지니스 오브젝트에서 사용할 수 있게 한다. 대표적인 선언적인 트랜잭션 서비스와 보안이다. 또한 EJB와 마찬가지로 오브젝트 컨테이너를 제공해서 인스턴스의 라이프사이클을 과리하고 필요에 따르 스레딩, 풀링 및 서비스 인젝션 등의 기능을 제공한다. 또한 OOP를 더  OOP답게 사용 할 수있게 하는 AOP기술을 적용해서 POJO개발을 더 쉽게 만든다. 

POJO프로그램의 진정한 가치는 자바의 객체지향적인 특징을 살려 비지니스 로직에 충실한 개발이 가능 하도록 하는것이기도 하다. 

내생각을 적자면 
평범한 자바 객체로 프로그래밍 하기라고 부르며, 침략적인 코드를 적지 않은 것이다. 
쉽게 말해 implement 와 extends를 사용 하지 않으며
콤포지션과 인터페이스타입으로 프로그래밍 하는것(이건 레디 존슨)

특정 클래스의 concrete class가 되면 안되고, 구현 체도 되면 안된다. 

아래 내용은 해당 블로그에서 가져왔습니다.

http://blog.naver.com/acatholic/90176619710


Comments