POJO 및 DAO에 관하여 --

POJO 및 DAO에 관하여 --

POJO = pure old Java object POJO에는 객체의 속성으로 private 매개 변수가 있습니다.그리고 매개 변수에 대한 get과 set 방법을 접근 인터페이스로 정의했습니다.예: public class User
private long id;
private String name;
public void setId(long id) {
this.id = id;
}
public void setName(String name) {
this.name=name;
}
public long getId() {
return id;
}
public String getName() {
return name;
}
}
POJO 대상은 때때로 Data 대상이라고도 불리며 현실을 표현하는 대상에 대량으로 응용된다.
따오다http://wiki.ccw.com.cn/POJO"

 

                                      
POJO = pure old java object or plain ordinary java object or what ever.
PO = persisent object 영구 객체
즉 일부 Object/Relation Mapping 도구에서 데이터베이스 테이블 기록을 유지할 수 있는persisent object는 자바빈 규범에 부합되는 순수한 자바 대상으로 다른 속성과 방법을 추가하지 않았다는 것이다.모두 이렇다.

public class User { 
  private long id; 
  private String name;
  public void setId(long id) {
 this.id = id;
}  
public void setName(String name) {
this.name=name;
} 
 public long getId() {
 return id;
}  
public String getName() { 
return name;
}
}  

우선 지구적 대상과 POJO를 구별해야 한다.
영구 대상은 실제적으로 데이터베이스에 있는entity에 대응해야 하기 때문에 POJO와 차이가 있다.예를 들어 POJO는 new에서 만들고 GC에서 회수합니다.그러나 지속 대상은 insert 데이터베이스에서 만들어지고 데이터베이스 delete에서 삭제됩니다.기본적으로 지속적인 대상의 생명주기는 데이터베이스와 밀접하게 관련되어 있다.또한 지속 대상은 데이터베이스 연결 하나만 존재할 수 있다. Connnection이 닫힌 후에 지속 대상은 존재하지 않는다. POJO는 GC에 회수되지 않으면 항상 존재한다.
여러 가지 차이가 존재하기 때문에 영구 대상인 PO(Persistent Object)는 코드상 POJO와 다를 것이다. 적어도 PO는 POJO에 비해 데이터베이스 entity 상태를 관리하는 속성과 방법을 추가할 것이다.ORM이 추구하는 목표는 PO를 사용할 때 POJO와 일치하도록 하는 것이다. 프로그래머에게 PO는 POJO로 사용할 수 있지만 PO의 존재를 느끼지 못한다.
JDO의 실현 방법은 다음과 같다.
1. POJO 작성
2. POJO 컴파일
3. JDO의 전문 도구인 Enhancer를 사용한다. 보통 명령행 프로그램으로 수동으로 실행하거나 ant 스크립트에서 실행한다. POJO의class 파일을 처리하고 POJO를 같은 이름의 PO로 바꾼다.
4. 운행 기간에 운행하는 것은 실제적으로 POJO이지 POJO가 아니다.
이 방법은 JSP와 약간 유사하다. JSP도 컴파일링 기간에 서브렛으로 변환되어 실행되고, 실행 기간에 실제로 실행되는 것은 서브렛이지 JSP가 아니다.
Hibernate는
1. POJO 작성
2. POJO 컴파일
3. 직접 운행하고 운행 기간에 Hibernate의 CGLIB에서 POJO를 PO로 동적으로 전환한다.
이를 통해 알 수 있듯이 Hibernate는 실행 기간에 POJO의 바이트 코드를 PO로 변환했고 JDO는 컴파일기에서 변환했다.일반적으로 JDO의 방식은 효율이 약간 높다고 여긴다. 왜냐하면 컴파일러 전환이잖아.그러나 Hibernate의 저자인 가빈킹은 CGLIB의 효율이 매우 높고 운행 기간의 PO의 바이트 코드 생성 속도가 매우 빠르기 때문에 효율 손실은 거의 무시할 수 없다고 말했다.
실제로 운행 기간에 PO를 생성하는 장점이 매우 크다. 이렇게 하면 프로그래머에게 PO를 접할 수 없고 PO는 그들에게 완전히 투명하다.POJO라는 개념으로 PO를 좀 더 자유롭게 조종할 수 있어요.또한 실행 기간에 PO를 생성하기 때문에 증량 컴파일링, 증량 디버깅을 지원할 수 있습니다.JDO는 이를 할 수 없었다.실제로 이미 많은 사람들이 JDO의 컴파일러 Enhancer 문제를 불평하고 있다. JBossDO는 실행 기간에 PO 바이트 코드를 생성하고 컴파일러에 PO 바이트 코드를 생성하지 않는다고 한다.
또 다른 문제는 JDO 제품에 따라 Enhancer가 생성한 PO 바이트 코드가 달라져 JDO 제품 간의 이식성에 영향을 미칠 수 있다는 점에서 EJB의 이식성 난제와 유사하다는 점이다.
이 문제에서 JDO의 결함을 별도로 끌어내다.
JDO의 PO 상태 관리 방식 때문에 프로그램에서 get/set을 사용할 때 실제로는 PO의 실례에서values를 찾지 않고 JDO State Manager를 사용합니까?에서 꺼내기 때문에 PM이 꺼지면 PO는 접근할 수 없습니다.
JDO에서 PO를 PM 밖에서 사용할 수 있는 방법도 있다. 예를 들어 PO가transient라고 정의하지만 이 PO는 PM이 닫힌 후에 PO identity가 없다.PM 간 상태 관리를 수행할 수 없습니다.
Hibernate는 PO 실례에서values를 추출하기 때문에 세션이 닫혀도 get/set으로 세션에 걸쳐 상태 관리를 할 수 있습니다.
여러 층으로 나뉘어진 응용에서 지구층과 업무층과 웹층이 분리되어 있기 때문에 이때Hibernate의 PO는 POJO로 사용할 수 있다. 즉, VO로 삼아 각 층 간에 자유롭게 전달할 수 있기 때문에Session이 켜져 있든 끄든 상관하지 않는다.이 POJO를 서열화하면 분포식 환경에서도 사용할 수 있습니다.(lazy loading에 적합하지 않은 경우)
그러나 JDO의 PO는 PM이 꺼진 후에 다시 사용할 수 없기 때문에 PM이 꺼지기 전에 PO를 VO로 복사하여 VO를 업무층과 웹층에 전달하여 사용해야 한다.비분포식 환경에서도 ThreadLocal 모드를 사용하여 PM이 항상 열려 있는지 확인하여 매번 PO에서 VO로 복사하는 작업을 피할 수 있다.그러나 어쨌든 이것은 항상 임시변통이어서 Hibernate의 기능보다 강하지 않다.
몇몇 명사를 변별하다.VO: 실제로는 매우 모호하다. 보통ValueObject와 ViewObject를 가리킨다.ViewObject, 인터페이스는 Struts의FormBean 3과 같은 필요한 대상을 보여 줍니다.초기에는 Value Object 및 Transfer Object의 총칭으로 사용되었습니다.실제로 Value Object의 진정한 의미는 ID 4가 아닌 내용에 있습니다.Transfer Object: 데이터 전송 대상, 응용 프로그램의 서로 다른 차원에서 책을 전달하는 대상, 분포식 응용 프로그램에서 전체적인 성능을 향상시킬 수 있습니다.PO:Persistent Object일지도 몰라요. 기본적으로 Entity예요. 서로 다른 체계 구조와 실현 방식에서 이런 대상들은 중복될 수도 있고 중첩되지 않을 수도 있어요.모든 체계를 쉽게 이식할 수 있는 틀을 만들려면 모든 대상을 엄격하게 구분해야 한다.예를 들어 JDO의 PO는 TO가 될 수 없기 때문에 PM에서 벗어날 수 없다. 예를 들어 ViewObject(예를 들어 Struts의FormBean)를 TO로 직접 선택할 수 있지만 Tapestry와 Webwork에서는 적합하지 않다.하지만 편리하고 실용적인 것이 가장 중요한 경우가 많으니 과도하게 디자인하지 마세요.
POJO는 이러한 대상이다. 이것은 일반적인 Java 대상이다. EJB와 같은 무거운 용기 제어 기능을 가진 대상과 다르다. Enhanced에 의해 만들어진 대상도 아니다. 예를 들어 JDO의 정적 Enhance도 아니고 Hibernate처럼 동적인byte code generation에 의해 만들어진 것도 아니다.즉 POJO의 개념은 다른 손발을 움직인 클라스에 비해 손발을 움직인 적이 없다는 것이다.사실, 왜 DAO를 해야 합니까?비단: 1, connection/transaction(hibernate면session/transaction)2를 관리하여 통계/log 조작에 편리하다.3. 권한 제어에 편리하다.DAO 모드에는 두 가지 유형의 객체가 있는데 하나는 DAO이고 하나는 valueObject입니다.이 시나리오에서 value object는hibernate에 대응하는 POJO입니다.그러면 제 이해에 따르면 DAO는 하나의 Transaction 포장기인데 그 논리적 구조는 바로 상업의 구체적인 사무입니다.이곳에서 데이터베이스의transaction과 상업적인 업무는 통일되어 있다.