나는 "Bean"이 속성과 getter/setter가 있는 Java 클래스라는 것을 이해했습니다. 내가 이해하는 한 그것은 C 구조체와 동일합니다. 사실인가요?
또한 Bean과 일반 클래스 사이에 실제 구문상의 차이가 있습니까? 특별한 정의나 인터페이스가 있습니까?
기본적으로 왜 이것에 대한 용어가 있습니까?
또한 Serializable
인터페이스는 무엇을 의미합니까?
질문자 :Amir Rachum
나는 "Bean"이 속성과 getter/setter가 있는 Java 클래스라는 것을 이해했습니다. 내가 이해하는 한 그것은 C 구조체와 동일합니다. 사실인가요?
또한 Bean과 일반 클래스 사이에 실제 구문상의 차이가 있습니까? 특별한 정의나 인터페이스가 있습니까?
기본적으로 왜 이것에 대한 용어가 있습니까?
또한 Serializable
인터페이스는 무엇을 의미합니까?
JavaBean은 표준일 뿐입니다.
Serializable
구현합니다.그게 다야 그냥 컨벤션입니다. 많은 라이브러리가 그것에 의존합니다.
API 문서 에서 Serializable
과 관련하여 :
클래스의 직렬화 가능성은 java.io.Serializable 인터페이스를 구현하는 클래스에 의해 활성화됩니다. 이 인터페이스를 구현하지 않는 클래스에는 직렬화 또는 역직렬화 상태가 없습니다. 직렬화 가능한 클래스의 모든 하위 유형은 자체적으로 직렬화 가능합니다. 직렬화 인터페이스에는 메소드나 필드가 없으며 직렬화 가능의 의미를 식별하는 역할만 합니다.
다시 말해서 직렬화 가능한 객체는 스트림에 기록될 수 있으며 따라서 파일, 객체 데이터베이스 등 모든 것이 가능합니다.
또한 JavaBean과 다른 클래스 사이에는 구문상의 차이가 없습니다. 클래스는 표준을 따르는 경우 JavaBean입니다.
표준은 라이브러리가 사전 정의된 방식으로 정의한 클래스 인스턴스로 프로그래밍 방식으로 작업을 수행할 수 있도록 허용하기 때문에 이에 대한 용어가 있습니다. 예를 들어 라이브러리가 전달한 객체를 스트리밍하려는 경우 객체가 직렬화 가능하기 때문에 스트리밍할 수 있다는 것을 알고 있습니다(라이브러리에서 객체가 적절한 JavaBean이어야 한다고 가정).
특별하게 들린다는 말이 있습니다. 현실은 그렇게 신비롭지 않습니다.
기본적으로 "콩":
java.io.Serializable
을 구현하고 올바르게 수행함).getFoo()
는 "Foo" 속성의 getter임) Serializable
관해서는 : 그것은 구현 클래스가 "직렬화"에 동의한다는 것을 Java에 알리는 "마커 인터페이스"(어떤 기능도 선언하지 않는 인터페이스)에 지나지 않습니다. 인스턴스를 바이트 스트림으로 변환합니다. 이러한 바이트는 파일에 저장될 수 있고 네트워크 연결 등을 통해 전송될 수 있으며 JVM(적어도 객체 유형에 대해 알고 있는)이 나중에 객체를 재구성할 수 있도록 충분한 정보를 가질 수 있습니다. 응용 프로그램 또는 전체 다른 컴퓨터에서!
물론 그렇게 하기 위해서는 클래스가 일정한 제한을 지켜야 한다. 그 중 가장 중요한 것은 모든 인스턴스 필드가 기본 유형(int, bool 등)이거나 직렬화 가능한 일부 클래스의 인스턴스이거나 Java가 포함하지 않도록 transient
(이 있음을 물론 수단의 transient
필드가있는 스트림입니다. 클래스를 통해 여행 살아남지 못할 것이다 transient
필드를 필요한 경우를 다시 초기화 할 준비를해야한다.)
이러한 제한을 준수 할 수없는 클래스는 구현하지 말아야 Serializable
(그리고, IIRC을, 자바 컴파일러는 심지어 그렇게하지 않습니다.)
JavaBeans는 매우 간단한 코딩 규칙을 따르는 Java 클래스입니다. 당신이해야 할 모든
java.io.Serializable
인터페이스 구현 - 객체의 상태 저장JavaBeans의 속성
JavaBean은 특정 프로그래밍 규칙을 충족하는 Java 객체입니다.
Serializable
또는 Externalizable
구현해야 합니다.
JavaBean 클래스에는 인수가 없는 생성자가 있어야 합니다.
모든 JavaBean 속성에는 공용 setter 및 getter 메서드가 있어야 합니다.
모든 JavaBean 인스턴스 변수는 비공개여야 합니다.
JavaBeans의 예
@Entity public class Employee implements Serializable{ @Id private int id; private String name; private int salary; public Employee() {} public Employee(String name, int salary) { this.name = name; this.salary = salary; } public int getId() { return id; } public void setId( int id ) { this.id = id; } public String getName() { return name; } public void setName( String name ) { this.name = name; } public int getSalary() { return salary; } public void setSalary( int salary ) { this.salary = salary; } }
예를 들어 설명합니다.
1. java.io.Serializable 가져오기
직렬화에 대해서는 설명서를 참조하십시오.
2. 개인 필드
외부 클래스가 해당 필드를 쉽게 수정할 수 없도록 필드는 비공개여야 합니다. 해당 필드에 직접 액세스하는 대신 일반적으로 getter/setter 메서드가 사용됩니다.
3. 생성자
인수가 없는 공용 생성자.
4. 게터/세터
개인 필드에 액세스하고 수정하기 위한 Getter 및 setter 메서드.
/** 1. import java.io.Serializable */ public class User implements java.io.Serializable { /** 2. private fields */ private int id; private String name; /** 3. Constructor */ public User() { } public User(int id, String name) { this.id = id; this.name = name; } /** 4. getter/setter */ // getter public int getId() { return id; } public String getName() { return name; } // setter public void setId(int id) { this.id = id; } public void setName(String name) { this.name = name; } }
Java Beans는 더 적은 코드와 더 많은 작업 접근 방식에 사용됩니다...
Java Bean은 Java EE 전체에서 런타임 검색 및 액세스를 위한 범용 계약으로 사용됩니다. 예를 들어, JSP(JavaServer Pages)는 페이지 간 또는 서블릿과 JSP 간의 데이터 전송 객체로 Java Beans를 사용합니다. Java EE의 JavaBeans Activation Framework는 MIME 데이터 유형에 대한 지원을 Java EE에 통합하기 위해 Java Beans를 사용합니다. Java EE 관리 API는 Java EE 환경에서 관리할 리소스 계측을 위한 기반으로 JavaBeans를 사용합니다.
직렬화 정보:
객체 직렬화에서 객체는 객체의 데이터와 객체의 유형 및 객체에 저장된 데이터 유형에 대한 정보를 포함하는 바이트 시퀀스로 나타낼 수 있습니다.
직렬화된 개체가 파일에 작성된 후에는 파일에서 읽고 역직렬화할 수 있습니다. 즉, 개체와 해당 데이터를 나타내는 유형 정보와 바이트를 사용하여 메모리에 개체를 다시 만들 수 있습니다.
빈이 유지되고 서버 간에 전송되므로 여러 서버에 프로젝트를 배포할 때 직렬화가 유용하다는 것을 알게 될 것입니다.
JavaBeans는 표준이며 기본 구문 요구 사항은 다른 답변에서 명확하게 설명되었습니다.
그러나 IMO는 단순한 구문 표준 이상입니다. JavaBeans의 진정한 의미 또는 의도된 사용은 표준 주변의 다양한 도구 지원과 함께 코드 재사용 및 구성 요소 기반 소프트웨어 엔지니어링을 용이하게 하는 것입니다. (또는 약간의 글루 코드만 작성하면 됩니다.) 불행히도 이 기술은 업계에서 과소 평가되고 활용도가 낮습니다. 이는 이 스레드의 답변에서 알 수 있습니다.
JavaBeans에 대한 Oracle의 자습서를 읽으면 이에 대해 더 잘 이해할 수 있습니다.
빈 개념에 대한 약간의 배경/업데이트. 다른 많은 답변은 실제로 무엇을 가지고 있지만 왜 그렇게 많지는 않습니다.
GUI 구축의 일부로 Java에서 초기에 발명되었습니다. 그들은 도구가 분리하기 쉬운 패턴을 따라 속성 패널을 생성하여 Bean의 속성을 편집할 수 있도록 했습니다. 일반적으로 Bean 속성은 화면의 컨트롤을 나타냅니다(x,y,width,height,text,..)
강력한 형식의 데이터 구조로 생각할 수도 있습니다.
시간이 지남에 따라 이들은 동일한 유형의 액세스를 사용하는 많은 도구에 유용하게 되었습니다(예: 데이터베이스에 데이터 구조를 유지하기 위한 Hibernate).
도구가 발전함에 따라 그들은 주석으로 더 이동했고 setter/getter 이름을 분리하는 것에서 멀어졌습니다. 이제 대부분의 시스템은 빈을 필요로 하지 않습니다. 빈을 조작하는 방법을 알려주기 위해 주석이 달린 속성이 있는 평범한 오래된 Java 객체를 사용할 수 있습니다.
이제 나는 빈을 주석이 달린 속성 공으로 본다. 그것들은 그들이 가지고 있는 주석에 대해서만 정말로 유용하다.
콩 자체는 건강한 패턴이 아닙니다. 그것들은 모든 속성을 외부 조작에 노출시키기 때문에 본질적으로 캡슐화를 파괴하고 사용됨에 따라 빈 내부에 코드를 생성하는 대신 외부에서 빈을 조작하는 코드를 생성하는 경향이 있습니다("돈 객체에게 값을 묻지 말고 객체에게 무언가를 요청하십시오"). 최소한의 getter와 setter가 없는 주석이 달린 POJO를 사용하는 것은 캡슐화를 복원하고 불변 가능성이 있는 훨씬 더 OO입니다.
그건 그렇고, 이 모든 일이 일어나고 있을 때 누군가가 개념을 Enterprise Java Beans라고 하는 것으로 확장했습니다. 이것들은... 다릅니다. 그리고 그것들은 많은 사람들이 전체 Bean 개념을 이해하지 못한다고 느끼고 용어 사용을 중단할 정도로 복잡합니다. 이것이 제 생각에 일반적으로 POJO라고 하는 빈을 듣는 이유입니다(모든 Java 객체는 POJO이므로 기술적으로 괜찮지만 누군가 POJO라고 말하는 것을 들을 때 가장 자주 빈 패턴을 따르는 것에 대해 생각하는 것입니다)
Wikipedia에 따르면:
클래스에는 인수가 없는 공용 기본 생성자가 있어야 합니다. 이를 통해 편집 및 활성화 프레임워크 내에서 쉽게 인스턴스화할 수 있습니다.
클래스 속성은 표준 명명 규칙에 따라 get, set, is(get 대신 부울 속성에 사용할 수 있음) 및 기타 메서드(소위 접근자 메서드 및 변경자 메서드)를 사용하여 액세스할 수 있어야 합니다. 이를 통해 프레임워크 내에서 빈 상태를 쉽게 자동으로 검사하고 업데이트할 수 있으며, 그 중 다수에는 다양한 유형의 속성에 대한 사용자 정의 편집기가 포함되어 있습니다. 세터는 하나 이상의 인수를 가질 수 있습니다.
클래스는 직렬화 가능해야 합니다. (이를 통해 애플리케이션과 프레임워크는 VM 및 플랫폼에 독립적인 방식으로 빈의 상태를 안정적으로 저장, 저장 및 복원할 수 있습니다.)
자세한 내용은 이 링크를 따르십시오.
질문의 두 번째 부분과 관련하여 직렬화 는 객체를 서명된 바이트 시퀀스로 저장하는 데 사용되는 지속성 메커니즘입니다. 덜 형식적으로 말하자면, 역직렬화를 통해 나중에 검색할 수 있도록 개체의 상태를 저장합니다.
Java Bean은 다음 규칙을 따라야 하는 Java 클래스(개념적)입니다.
재사용 가능한 소프트웨어 구성 요소입니다. 많은 개체를 하나의 개체로 캡슐화하여 여러 위치에서 동일한 개체에 액세스할 수 있으며 코드를 쉽게 유지 관리할 수 있는 단계입니다.
직렬화 가능하고 인수가 없는 생성자가 있으며 getter 및 setter 메서드를 사용하여 속성에 액세스할 수 있습니다. "Bean"이라는 이름은 Java용 재사용 가능한 소프트웨어 구성 요소를 만드는 것을 목표로 하는 이 표준을 포함하기 위해 주어졌습니다. Wikipedia 에 따르면 .
애플리케이션의 백본을 형성하고 Spring IoC 컨테이너에 의해 관리되는 객체를 빈이라고 합니다. 빈은 인스턴스화, 조립 및 Spring IoC 컨테이너에 의해 관리되는 객체입니다. 그렇지 않으면 빈은 애플리케이션에 있는 많은 객체 중 하나일 뿐입니다. Spring IoC 에 따르면 .
Java Bean은 다음 세 가지 기준을 충족하는 모든 Java 클래스입니다.
serialVersionUID 필드는 객체 상태를 유지하는 데 중요합니다.
아래 코드는 빈으로 간주됩니다.
public class DataDog implements java.io.Serializable { private static final long serialVersionUID = -3774654564564563L; private int id; private String nameOfDog; // The constructor should NOT have arguments public DataDog () {} /** 4. getter/setter */ // Getter(s) public int getId() { return id; } public String getNameOfDog() { return nameOfDog; } // Setter(s) public void setId(int id) { this.id = id; } public void setNameOfDog(String nameOfDog) { this.nameOfDog = nameOfDog; }}
빈 은 속성 , 메서드 및 이벤트에 대한 JavaBean 지침(디자인 패턴이라고도 함)을 따르는 메서드 이름을 가진 Java 클래스입니다. 따라서 속성 정의의 일부가 아닌 빈 클래스의 모든 공용 메서드는 빈 메서드입니다. 최소한 Java 클래스는 속성이 단독 멤버로 포함되어 있어도(물론 공개 getter 및 setter가 필요함), 공개 메서드가 단독 멤버로 사용되거나 하나의 공개 이벤트 리스너 등록 메서드만 Java 빈입니다. 또한 속성은 읽기 전용 속성(getter 메서드는 있지만 setter 없음) 또는 쓰기 전용 속성(setter 메서드만 있음)일 수 있습니다. Java bean은 모든 beanbox 도구 또는 컨테이너에서 볼 수 있는 공용 클래스여야 합니다. 컨테이너는 이를 인스턴스화할 수 있어야 합니다. 따라서 public 생성자도 있어야 합니다. JavaBeans 사양 은 컨테이너가 인스턴스화할 수 있도록 명시적이든 기본값이든 0이 없는 공개 생성자를 Bean에 요구하지 않습니다. 직렬화된 인스턴스를 포함하는 파일(확장자 .ser 포함)을 제공할 수 있는 경우 빈박스 도구는 해당 파일을 사용하여 프로토타입 빈을 인스턴스화할 수 있습니다. 그렇지 않으면 빈은 명시적이든 기본값이든 공개 제로 인수 생성자가 필요합니다.
Bean이 인스턴스화되면 JavaBean API( java.beans.*)가 이를 자체 검사하고 이에 대한 메소드를 호출할 수 있습니다. 인터페이스 BeanInfo를 구현하거나 BeanInfo 구현을 확장하는 클래스가 없는 경우 SimpleBeanInfo 클래스를 사용할 수 있는 경우 자체 검사는 대상 빈에서 지원하는 메서드를 연구하기 위해 반사(암시적 내부 검사)를 사용하고 다음에서 추론할 간단한 디자인 패턴(지침)을 적용하는 것을 포함합니다. 속성, 이벤트 및 공용 메서드가 지원되는 메서드입니다. 인터페이스 BeanInfo를 구현하는 클래스(Bean Foo의 경우 이름이 FooBeanInfo여야 함)를 사용할 수 있는 경우 API는 암시적 내부 검사를 우회하고 이 클래스의 공개 메소드(getPropertyDescriptor(), getMethodDescriptors(), getEventSetDescriptors())를 사용하여 정보. SimpleBeanInfo를 확장하는 클래스가 사용 가능한 경우 SimpleBeanInfo 공개 메소드(getPropertyDescriptor(), getMethodDescriptors(), getEventSetDescriptors()) 중 어느 것이 재정의되었는지에 따라 재정의된 메소드를 사용하여 정보를 얻습니다. 재정의되지 않은 메서드의 경우 기본적으로 해당 암시적 내부 검사가 사용됩니다. 암시적 내부 검사가 수행되지 않더라도 빈은 어쨌든 인스턴스화되어야 합니다. 따라서 공개 제로 인수 생성자가 필요합니다. 그러나 물론 Serializable 또는 Externalizable 인터페이스는 인식할 필요가 없습니다. 그러나 Java Bean 사양은 '단순히 내부 상태를 저장하기를 원하고 그것에 대해 생각하고 싶지 않은 작은 Bean의 일반적인 경우에 대해 "사소한" 것을 원합니다.' 따라서 모든 Bean은 Serializable 또는 Externalizable 인터페이스를 구현해야 합니다.
전반적으로 JavaBeans 사양은 빈을 구성하는 요소에 대해 어렵지 않고 빠르지 않습니다. "JavaBeans 구성 요소를 작성하는 것은 놀라울 정도로 쉽습니다. 특별한 도구가 필요하지 않으며 인터페이스를 구현할 필요도 없습니다. 빈을 작성하는 것은 단순히 특정 코딩 규칙을 따르는 문제입니다. 클래스가 다음과 같이 보이도록 만들기만 하면 됩니다. bean — bean을 사용하는 도구는 bean을 인식하고 사용할 수 있습니다." 당연하게도 다음 클래스도 자바 빈이다.
public class Trivial implements java.io.Serializable {}
아래에 설명된 Bean은 위에서 설명한 Java SE 버전(JavaBeans)의 Java EE 버전입니다. 이러한 설명은 위에서 설명한 기본 아이디어를 추가로 설명합니다.
봄 콩
예를 들어 빈 생성자에는 몇 가지 매개변수가 있습니다. 일부가 단순 유형이라고 가정합니다. 컨테이너는 할당할 값을 모를 수 있습니다. 사용하더라도 결과 인스턴스는 재사용할 수 없습니다. 사용자가 Spring bean에서와 같이 주석 또는 xml 구성 파일을 사용하여 구성(값 지정)할 수 있는 경우에만 의미가 있을 수 있습니다. 그리고 일부 매개변수가 클래스 또는 인터페이스 유형이라고 가정합니다. 다시 말하지만, 컨테이너는 할당할 값을 모를 수 있습니다. 사용자가 주석 또는 xml 구성 파일을 사용하여 구성(특정 개체 지정)할 수 있는 경우에만 의미가 있을 수 있습니다. 그러나 Spring에서도(xml 구성 파일을 통해) 특정 객체(문자열 이름 포함)를 생성자 인수(생성자 인수의 속성 또는 요소)에 할당하는 것은 유형 안전하지 않으며 기본적으로 리소스 주입과 같습니다. 다른 Spring 빈(협력자라고 함, 생성자 인수 요소의 요소를 통해)에 대한 참조를 만드는 것은 기본적으로 종속성 주입이므로 유형이 안전합니다. 분명히 종속성(collaborator bean)에는 매개변수가 삽입된 생성자가 있을 수 있습니다. 주입된 종속성에는 매개변수 등이 있는 생성자가 있을 수 있습니다. 이 시나리오에서는 궁극적으로 컨테이너가 생성자에 대한 종속성 주입을 통해 다른 협업 빈을 구성하기 전에 단순히 new MyBean()을 호출하여 인스턴스화할 수 있는 몇 가지 빈 클래스(예: MyBean.class)가 필요합니다. 빈은 공개 제로 인수 생성자를 갖습니다. 컨테이너가 종속성 주입을 지원하지 않거나 Spring에서와 같이 일부 주석 또는 xml 구성 파일을 통해 생성자에 단순 유형 값을 할당하는 것을 허용하지 않는 경우 빈 생성자에 매개변수가 없어야 한다고 가정합니다. Spring bean 애플리케이션조차도 public 0-args 생성자를 갖기 위해 몇몇 bean이 필요할 것이다(예를 들어 Spring 애플리케이션이 생성자 인수로 단순한 유형을 가진 bean이 없는 시나리오에서).
JSF 관리 빈
JSF 관리 Bean은 웹 컨테이너에서 실행됩니다. @ManagedBean 주석 또는 응용 프로그램 구성 리소스 파일 managed-bean.xml을 사용하여 구성할 수 있습니다. 그러나 리소스 주입(유형 안전 아님)을 통한 주입만 지원합니다. 생성자에 주입하기에 적합하지 않습니다. JSF 사양 에서는 관리되는 빈에 인수가 없는 공개 생성자가 있어야 한다고 요구합니다. 또한 "이 사양의 버전 2.3에서 이 섹션에 지정된 관리되는 빈 기능의 사용은 강력히 권장되지 않습니다. 동일한 문제를 해결하기 위한 더 우수하고 응집력 있는 통합 솔루션은 JSR-365에 지정된 대로 컨텍스트 및 종속성 주입(CDI)을 사용하는 것입니다. CDI 사양은 Web Tier 뿐만 아니라 JEE 플랫폼의 모든 컨테이너에 적용되는 Managed Beans 사양을 채택하고 있으므로 웹 컨테이너는 CDI 사양을 구현해야 합니다.
관리되는 빈
다음은 Managed Bean 사양 에서 발췌한 것입니다. " Managed Beans는 최소한의 요구 사항을 가진 컨테이너 관리 개체입니다. 그렇지 않으면 "POJOs"(Plain Old Java Objects)라는 약어로 알려져 있습니다… Java SE 플랫폼에서 찾은 JavaBeans 구성 요소 모델… 독자는 Managed Beans가 JSF(JavaServer Faces) 기술에서 발견되는 동형 기능의 전구체를 가지고 있다는 사실을 놓치지 않을 것입니다… 이 사양에 정의된 Managed Beans는 JSF에서 발견된 것들의 일반화를 나타냅니다. 특히 Managed Beans는 웹 모듈뿐만 아니라 Java EE 애플리케이션의 모든 곳에서 사용할 수 있습니다. 예를 들어, 기본 구성 요소 모델에서 Managed Beans는 인수가 없는 생성자를 제공해야 하지만 CDI(JSR-299)와 같은 Managed Beans를 기반으로 하는 사양은 해당 요구 사항을 완화하고 Managed Beans가 생성자에게 더 많은 것을 제공하도록 허용할 수 있습니다. 잘 정의된 규칙을 따르는 한 복잡한 서명... 관리되는 빈은 다음과 같은 경우가 아니어야 합니다. 최종 클래스, 추상 클래스, 비정적 내부 클래스. Managed Bean은 일반 JavaBean 구성 요소와 달리 직렬화할 수 없습니다." 따라서 POJO 또는 POJO Bean으로 알려진 Managed Bean에 대한 사양은 CDI에서와 같이 확장을 허용합니다.
CDI 빈
CDI 사양 은 관리 Bean을 다음과 같이 재정의합니다. Java EE에서 실행할 때 최상위 Java 클래스는 요구 사항을 충족하는 경우 관리 Bean입니다.
• 내부 클래스가 아닙니다. • 비추상 클래스이거나 @Decorator 주석이 있습니다. • javax.enterprise.inject.spi.Extension을 구현하지 않는다. • @Vetoed 주석이 없거나 @Vetoed 주석이 있는 패키지에 없습니다. • 적절한 생성자가 있습니다. 클래스에 매개변수가 없는 생성자가 있거나 클래스가 @Inject 주석이 달린 생성자를 선언합니다.
이러한 조건을 충족하는 모든 Java 클래스는 관리되는 빈이므로 관리되는 빈을 정의하기 위해 특별한 선언이 필요하지 않습니다. 또는
다른 Java EE 사양에 의해 관리되는 빈으로 정의된 경우
• EJB 컴포넌트 정의 어노테이션으로 어노테이션을 붙이지 않거나 ejb-jar.xml에서 EJB 빈 클래스로 선언하지 않는다.
Spring Bean과 달리 단순 유형의 생성자를 지원하지 않습니다. Spring 또는 모든 주석과 같은 xml 구성 파일로 구성을 지원하는 경우 가능할 수 있습니다.
EJB
EJB는 EJB 컨테이너에서 실행됩니다. 사양 에는 "세션 빈 구성 요소는 관리되는 빈입니다." "클래스에는 인수를 사용하지 않는 공용 생성자가 있어야 합니다." 세션 빈과 메시지 구동 빈 모두에 대해 나와 있습니다. 또한 "세션 빈 SessionBean 인터페이스 또는 Serializable 인터페이스를 구현하는 데 클래스가 필요하지 않습니다." EJB3 의존성 주입이 기본적으로 자원 주입이라는 JSF 빈과 같은 이유로 JSF 빈은 인수가 있는 생성자를 지원하지 않는다. Inject 주석으로 주석이 달린 추가 생성자는 " 세션 Bean과 메시지 구동 Bean 모두에 대해 말합니다. 콩."
JavaBean을 이해하려면 다음 사항에 유의해야 합니다.
JavaBean은 개념적 항목이며 특정 항목의 클래스를 나타낼 수 없습니다.
JavaBean은 재사용 가능한 소프트웨어 구성 요소의 작업에서 시각화할 수 있는 개발 도구입니다.
JavaBean은 Sun JavaBeans 사양을 기반으로 하며 재사용 가능한 구성 요소가 될 수 있습니다. 가장 큰 특징은 재사용성입니다.
POJO (plain old Java object): POJO는 Java 언어에 의해 강제되는 것 외에 다른 제한이 없는 일반 Java 객체입니다.
직렬화: 객체의 상태를 저장 하고 네트워크를 통해 전송하는 데 사용됩니다. 객체의 상태를 바이트 스트림으로 변환합니다. deserialization 이라는 프로세스를 통해 바이트 스트림에서 Java 객체를 다시 생성할 수 있습니다.
클래스가 java.io.Serializable 인터페이스를 구현하도록 합니다. 그리고 ObjectOutputStream 클래스의 writeObject() 메서드를 사용하여 직렬화를 달성합니다.
JavaBean 클래스: 일부 제한(또는 규칙)이 있는 특수 POJO입니다.
Spring과 같은 많은 프레임워크는 JavaBean 객체를 사용합니다.
C/Golang에 익숙하다면 C bean이나 Go bean은 struct
키워드를 가지고 있기 때문에 들어본 적이 없을 것입니다. 개발자는 복잡한 OOP 키워드를 작성하지 않고도 쉽게 구조 유형을 정의할 수 있습니다.
type User struct { Name string Age int } var user User user.Name = "name" user.Age = 18 var bytes, err = json.Marshal(user)
struct
유형이 부족한 것은 Java의 실수이며 개발자는 이러한 부족을 심하게 찾습니다.
struct
가장하는 class
를 만드는 또 다른 지루한 규칙으로 발명되었습니다. 편집기나 컴파일러는 클래스 멤버에 대한 안전하지 않은 액세스에 대해 울거나 소리지르지 않을 것입니다.
Beans 애플리케이션의 백본을 형성하고 Spring IoC 컨테이너에 의해 관리되는 객체를 Bean이라고 합니다. 빈은 인스턴스화, 조립 및 Spring IoC 컨테이너에 의해 관리되는 객체입니다. 이러한 빈은 컨테이너에 제공하는 구성 메타데이터로 생성됩니다.
실제로 Bean은 사용하기 편리한 객체일 뿐입니다. 직렬화한다는 것은 쉽게 유지할 수 있음을 의미합니다(쉽게 복구할 수 있는 형태로 저장).
실제 세계에서 Bean의 일반적인 용도:
그래서 사실, Beans는 자바 객체가 동작(직렬화)하고 특정 방식으로 이를 변경할 수 있는 몇 가지 방법(속성에 대한 설정자)을 제공하기 위한 규칙/표준일 뿐입니다.
그것들을 사용하는 방법은 단지 당신의 발명품일 뿐이지만, 제가 위에 열거한 가장 일반적인 경우입니다.
Java Bean은 JavaBeans 아키텍처의 구성 요소 또는 기본 빌딩 블록입니다. JavaBeans 아키텍처는 구성 요소 기반 접근 방식의 재사용성과 상호 운용성을 활용하는 구성 요소 아키텍처입니다.
유효한 구성 요소 아키텍처는 다른 공급업체에서 제공하는 소프트웨어 빌딩 블록(이 경우 Bean)에서 프로그램을 조합할 수 있도록 해야 하며 설계자/개발자가 구성 요소(Bean)를 선택하고 해당 기능을 이해하고 통합할 수 있도록 해야 합니다. 응용 프로그램으로.
클래스/객체는 Java와 같은 OOP 언어의 기본 빌딩 블록이기 때문에 JavaBeans 아키텍처에서 Bean이 되기 위한 자연스러운 경쟁자입니다.
일반 Java 클래스를 Java bean으로 변환하는 프로세스는 실제로 재사용 가능하고 상호 운용 가능한 구성 요소로 만드는 것 이상입니다. 이것은 다음과 같은 기능을 가진 Java 클래스로 변환됩니다.
Java 클래스를 Java bean이라고 하기 위해 위의 모든 기능을 소유할 필요는 없습니다. 대신, 컨텍스트와 관련된 위의 하위 집합을 구현하는 것을 의미합니다(예: 특정 프레임워크의 빈에는 사용자 정의자가 필요하지 않을 수 있고, 일부 다른 빈에는 바인딩 및 제한 속성이 필요하지 않을 수 있습니다).
Java의 거의 모든 주요 프레임워크 및 라이브러리는 위의 이점을 얻기 위해 암시적으로 JavaBeans 아키텍처를 준수합니다.
Spring @Bean 어노테이션은 메소드가 Spring 컨테이너에 의해 관리될 Bean을 생성함을 나타냅니다.
추가 참조: https://www.concretepage.com/spring-5/spring-bean-annotation
JavaBeans에 대해 인수가 없는 생성자 요구사항이 있다는 것은 위에서 6~7번 반복되었습니다.
이것은 잘못된 것입니다. 특히 Java Spring의 컨텍스트에서는 그러한 요구 사항이 없습니다.
JavaBeanns API를 설명하는 사양 버전(1.01)에도 해당 요구 사항에 대한 언급이 없습니다( https://download.oracle.com/otndocs/jcp/7224-javabeans-1.01-fr-spec-oth-JSpec/ ). 더군다나 이 사양은 다음 컨텍스트에서 'null 생성자'를 2번만 언급합니다. "각 사용자 지정 프로그램에는 null 생성자가 있어야 합니다." "각 PropertyEditor에는 null 생성자가 있어야 합니다."
따라서 사양 작성자가 "null 생성자"라는 용어를 모르거나 사용할 의사가 없는 것처럼 보이지만 적절한 JavaBeans에 대해 여전히 이에 대한 언급이 없습니다.
출처 : http:www.stackoverflow.com/questions/3295496/what-is-a-javabean-exactly
파이썬에서 객체에 속성이 있는지 확인하는 방법 (0) | 2021.12.07 |
---|---|
Node.js에서 종료하는 방법 (0) | 2021.12.07 |
Android에서 Python을 실행하는 방법이 있습니까? (0) | 2021.12.07 |
메소드와 함수의 차이점은 무엇입니까? (0) | 2021.12.07 |
Git으로 특정 태그 다운로드 (0) | 2021.12.06 |