비슷한 질문을 보았습니다.
그것들이 사용되는 상황을 알려주시겠습니까? 아니면 그 목적입니까?
답변:
JavaBean은 Sun에서 정의한 JavaBeans 규칙 을 따르는 클래스입니다 . Wikipedia에는 JavaBeans에 대한 요약이 있습니다.
JavaBeans는 빌더 도구에서 시각적으로 조작 할 수있는 Java 용 재사용 가능한 소프트웨어 구성 요소입니다. 실제로는 특정 규칙에 따라 Java 프로그래밍 언어로 작성된 클래스입니다. 그것들은 많은 객체를 단일 객체 (콩)로 캡슐화하여 여러 개의 개별 객체 대신 단일 콩 객체로 전달할 수 있습니다. JavaBean은 직렬화 가능하고 널 생성자가 있으며 Java getter 및 setter 메소드를 사용하여 특성에 액세스 할 수있는 Java 오브젝트입니다.
JavaBean 클래스로 기능하려면 오브젝트 클래스가 메소드 이름 지정, 구성 및 동작에 대한 특정 규칙을 준수해야합니다. 이러한 규약은 JavaBean을 사용, 재사용, 교체 및 연결할 수있는 도구를 사용할 수있게합니다.
필요한 규칙은 다음과 같습니다.
- 클래스에는 공개 기본 생성자가 있어야합니다. 이를 통해 편집 및 활성화 프레임 워크 내에서 쉽게 인스턴스화 할 수 있습니다.
- 클래스 속성은 표준 명명 규칙에 따라 get, set 및 기타 메서드 (소위 접근 자 메서드 및 변경자 메서드)를 사용하여 액세스 할 수 있어야합니다. 이를 통해 프레임 워크 내에서 빈 상태를 쉽게 자동으로 검사하고 업데이트 할 수 있으며, 여기에는 다양한 유형의 특성에 대한 사용자 정의 편집기가 포함됩니다.
- 클래스는 직렬화 가능해야합니다. 이를 통해 애플리케이션 및 프레임 워크가 VM 및 플랫폼과 독립적 인 방식으로 Bean의 상태를 안정적으로 저장, 저장 및 복원 할 수 있습니다.
이러한 요구 사항은 인터페이스를 구현하는 것이 아니라 일반적으로 규칙으로 표현되기 때문에 일부 개발자는 JavaBean을 특정 이름 지정 규칙을 따르는 일반 Old Java 오브젝트로 간주합니다.
POJO (Plain Old Java Object)는 javax.ejb헤비급 EJB 2.x (특히 Entity Bean, Stateless Session Beans가 나쁜 IMO가 아님)와는 달리 인터페이스를 구현하지 않고 간단한 경량 Java 오브젝트를 지정하기 위해 처음 도입 된 용어 입니다. 오늘날이 용어는 추가 항목이없는 간단한 객체에 사용됩니다. 다시 한 번 Wikipedia는 POJO 를 정의하는 데 능숙합니다 .
POJO는 Plain Old Java Object의 약어입니다. 이 이름은 문제의 객체가 특별한 객체가 아닌 일반적인 Java 객체이며 특히 Enterprise JavaBean이 아니라는 것을 강조하기 위해 사용됩니다 (특히 EJB 3 이전). 이 용어는 2000 년 9 월 Martin Fowler, Rebecca Parsons 및 Josh MacKenzie에 의해 만들어졌습니다.
"우리는 왜 사람들이 시스템에서 일반 객체를 사용하는 것에 반대하는지 궁금해했고 단순한 객체에는 이름이 부족했기 때문이라고 결론을 내 렸습니다.
이 용어는 전화 통신의 POTS (Plain Old Telephone Service)와 같은 새로운 기능을 사용하지 않는 기술과 C ++로 정의되었지만 C 언어 기능 만 사용하는 PODS (Plain Old Data Structures)와 같은 기존 용어의 패턴을 계속합니다. 및 Perl의 POD (Plain Old Documentation).
이 용어는 복잡한 객체 프레임 워크와 대조되는 일반적이고 쉽게 이해되는 용어가 필요하기 때문에 널리 받아 들여졌습니다. JavaBean은 직렬화 가능한 POJO이며 인수가없는 생성자를 가지며 getter 및 setter 메소드를 사용하여 특성에 액세스 할 수 있습니다. Enterprise JavaBean은 단일 클래스가 아니라 전체 구성 요소 모델입니다 (EJB 3은 Enterprise JavaBean의 복잡성을 줄입니다).
POJO를 사용하는 설계가보다 일반적으로 사용됨에 따라 POJO에게 프레임 워크에 사용되는 일부 기능을 제공하고 실제로 어떤 기능 영역이 필요한지 더 많은 선택권을주는 시스템이 생겨났습니다. 최대 절전 모드와 스프링이 예입니다.
값 개체 또는 VO는 java.lang.Integer값을 보유 하는 개체 (따라서 값 개체)입니다. 좀 더 공식적인 정의를 위해 나는 종종 Martin Fowler의 Value Object에 대한 설명을 참조한다 .
Enterprise Application Architecture의 패턴에서 Value Object를 Money 또는 날짜 범위 오브젝트와 같은 작은 오브젝트로 설명했습니다. 그들의 주요 속성은 참조 의미론보다 가치 의미론을 따르는 것입니다.
평등에 대한 개념은 동일성을 기반으로하지 않기 때문에 일반적으로 알 수 있습니다. 대신 모든 필드가 동일하면 두 개의 값 객체가 동일합니다. 모든 필드가 동일하지만 하위 집합이 고유 한 경우 모든 필드를 비교할 필요는 없습니다. 예를 들어 통화 개체의 통화 코드가 동등성을 테스트하기에 충분합니다.
일반적인 휴리스틱은 가치 객체가 완전히 변경 불가능하다는 것입니다. 값 개체를 변경하려면 개체를 새 개체로 바꾸고 값 개체 자체의 값을 업데이트 할 수 없어야합니다. 업데이트 가능한 값 개체는 앨리어싱 문제를 일으 킵니다.
초기 J2EE 문헌은 value object라는 용어를 사용하여 다른 개념, 즉 데이터 전송 오브젝트 라고하는 개념을 설명했습니다 . 그 이후로 사용법을 변경하고 대신 Transfer Object 라는 용어를 사용합니다 .
위키 와 Dirk Riehle 의 가치 객체에 대한 더 좋은 자료를 찾을 수 있습니다 .
데이터 전송 객체 또는 DTO는 EJB와 함께 도입 된 안티 패턴입니다. EJB에서 많은 원격 호출을 수행하는 대신, 네트워크를 통해 전송할 수있는 가치 객체 (데이터 전송 객체)에 데이터를 캡슐화하는 것이 아이디어였습니다. Wikipedia에는 Data Transfer Object에 대한 적절한 정의가 있습니다 .
이전에는 값 개체 또는 VO라고 알려진 DTO (데이터 전송 개체)는 소프트웨어 응용 프로그램 하위 시스템간에 데이터를 전송하는 데 사용되는 디자인 패턴입니다. DTO는 종종 데이터베이스에서 데이터를 검색하기 위해 데이터 액세스 개체와 함께 사용됩니다.
데이터 전송 개체와 비즈니스 개체 또는 데이터 액세스 개체의 차이점은 DTO가 자체 데이터 (접근 자 및 뮤 테이터)의 저장 및 검색을 제외하고는 동작이 없다는 것입니다.
전통적인 EJB 아키텍처에서 DTO는 이중 목적을 제공합니다. 첫째, 엔티티 bean이 직렬화 할 수 없다는 문제를 해결합니다. 둘째, 이들은 뷰에 의해 사용될 모든 데이터가 프리젠 테이션 티어로 제어를 리턴하기 전에 DTO로 페치 및 마샬링되는 어셈블리 단계를 암시 적으로 정의한다.
따라서 많은 사람들에게 DTO와 VO는 동일합니다 (그러나 Fowler는 VO를 사용하여 우리가 본 다른 것을 의미합니다). 대부분의 경우 JavaBeans 규칙을 따르므로 JavaBeans이기도합니다. 그리고 모두 POJO입니다.
class SomeClass { public String foo;public String bar; }복잡한 논리가 많은 클래스 내에서 이와 같은 관련이없는 데이터를 전송하기 위해 작성된 편리한 클래스가 있다면 JavaBean이 아니기 때문에 변경 가능하므로 VO가 될 수 없습니다. DTO? 그것은 어떤 종류의 원격 호출을 목표로하지 않았습니다. POJO로 간주 될 수 있습니까?
DTO 대 VO
DTO- 데이터 전송 개체는 계층과 계층간에 데이터를 전송하는 데 사용되는 데이터 컨테이너입니다.
유추 :
속성 사용자 이름, 비밀번호 및 이메일 ID를 가진 간단한 등록 양식.
- 이 양식이 RegistrationServlet 파일로 제출되면 속성을 Java Bean에 전달한 다음 DAO 또는 지속성 계층에 속성을 전달하는보기 계층에서 비즈니스 계층으로 모든 속성을 가져옵니다.
- DTO는 속성을 뷰 계층에서 비즈니스 계층으로, 마지막으로 지속성 계층으로 전송하는 데 도움을줍니다.
DTO는 주로 네트워크를 통해 데이터를 효율적으로 전송하는 데 사용되었으며 JVM에서 다른 JVM으로도 사용될 수 있습니다.
DTO는 종종 java.io.SerializableJVM을 통해 데이터를 전송하기 위해 사용됩니다.
VO- Value Object [1] [2]는 고정 된 데이터 세트를 나타내며 Java 열거 형과 유사합니다. Value Object의 아이덴티티는 객체 아이덴티티가 아닌 상태를 기반으로하며 불변입니다. 실제 예는 Color.RED, Color.BLUE, SEX.FEMALE 등입니다.
POJO 및 JavaBeans
[1] POJO의 Java-Beanness는 개인 속성이 모두 JavaBeans 규칙을 준수하는 공용 게터 및 세터를 통해 액세스된다는 것입니다. 예 :
private String foo;
public String getFoo(){...}
public void setFoo(String foo){...}; [2] JavaBeans는 Serializable을 구현하고 인수가없는 생성자를 가져야하지만 POJO에는 이러한 제한이 없습니다.
Java Bean은 EJB와 다릅니다.
Java 1.0 의 JavaBeans 사양 은 VB처럼 보이는 IDE에서 Java 객체를 조작 할 수있게하려는 Sun의 시도였습니다. "Java Beans"로 규정 된 오브젝트에 대해 규칙이 작성되었습니다.
EJB는 나중에 나왔습니다. 스레드, 풀링, 수명주기를 관리하고 서비스를 제공하는 컨테이너에서 실행되는 분산 구성 요소와 트랜잭션 모델을 결합합니다. 그들은 Java Beans와는 거리가 멀다.
사람들은 EJB 1.0 스펙이 데이터베이스에 너무 "충분하다"는 것을 알게 되었기 때문에 DTO는 Java 컨텍스트에서 등장했습니다. 사람들은 모든 데이터 요소에 대해 왕복 여행을하는 대신, Java Beans에 대량으로 패키지하여 발송할 것입니다.
POJO는 EJB에 대한 반응이었습니다.
POJO : 그것은 다른 자바 파일 (클래스)을 확장하거나 구현하지 않는 자바 파일 (클래스)입니다.
Bean : 모든 변수가 전용이고 메소드가 공용이며 변수에 액세스하는 데 적절한 getter 및 setter가 사용되는 Java 파일 (클래스)입니다.
일반 클래스 : 공개 / 개인 / 기본 / 보호 변수로 구성되고 다른 Java 파일 (클래스)을 확장하거나 구현하지 않을 수있는 Java 파일 (클래스)입니다.
첫 이야기
일반 클래스 - 이는 일반적으로 Java에서 클래스를 정의한다는 것을 의미합니다. 이는 다른 유형의 메소드 특성 등 을 작성 함을 의미합니다 .
Bean- Bean은 아무것도 아닙니다.이 Bean을 사용하여 특정 클래스의 오브젝트 일 뿐이므로 오브젝트와 동일한 Java 클래스에 액세스 할 수 있습니다. .
마지막 POJO에 대한 이야기 후
POJO - POJO 는 서비스가없는 클래스로 기본 생성자 및 private 속성과 값에 해당하는 setter 및 getter 메서드를 설정하기위한 속성 만 있습니다. 간단한 Java 객체의 짧은 형식입니다.