JavaBeans가 사용되는 장소?

JavaBeans가 사용되는 장소?

---

JavaBean이란 무엇이며 왜 필요한가요? 클래스와 인터페이스 구조로 모든 앱을 만들 수 있습니까? 왜 콩이 필요한가요? 그리고 클래스와 인터페이스 대신에 bean이 필수적인 예제를 제공해 줄 수 있습니까?

아래 문맥에서 빈의 중요성을 설명하십시오.

• apps 앱
• 독립형 앱

---

그들은 종종 실제 데이터를 나타냅니다. 다음은 Javabean의 간단한 예입니다.

public class User implements java.io.Serializable {

    // Properties.
    private Long id;
    private String name;
    private Date birthdate;

    // Getters.
    public Long getId() { return id; }
    public String getName() { return name; }
    public Date getBirthdate() { return birthdate; }

    // Setters.
    public void setId(Long id) { this.id = id; }
    public void setName(String name) { this.name = name; }
    public void setBirthdate(Date birthdate) { this.birthdate = birthdate; }

    // Important java.lang.Object overrides.
    public boolean equals(Object other) {
        return (other instanceof User) && (id != null) ? id.equals(((User) other).id) : (other == this);
    }
    public int hashCode() {
        return (id != null) ? (getClass().hashCode() + id.hashCode()) : super.hashCode();
    }
    public String toString() {
        return String.format("User[id=%d,name=%s,birthdate=%d]", id, name, birthdate);
    }
}

구현 Serializable은 필수적이지 않지만 하드 디스크 나 네트워크 등의 Java 메모리 외부에서 Javabean을 유지하거나 전송할 수있는 경우 매우 유용합니다.

예를 들어 DAO 클래스에서이 테이블 을 사용하여 테이블 의 데이터를 데이터베이스에 저장 하는 사용자 목록을 만들 수 있습니다 user.

List<User> users = new ArrayList<User>();
while (resultSet.next()) {
    User user = new User();
    user.setId(resultSet.getLong("id"));
    user.setName(resultSet.getString("name"));
    user.setBirthdate(resultSet.getDate("birthdate"));
    users.add(user);
}
return users;

In for example a Servlet class you can use it to transfer data from the database to the UI:

protected void doGet(HttpServletRequest request, HttpServletResponse response) {
    List<User> users = userDAO.list();
    request.setAttribute("users", users);
    request.getRequestDispatcher("users.jsp").forward(request, response);
}

In for example a JSP page you can access it by EL, which follows the Javabean conventions, to display the data:

<table>
    <tr>
        <th>ID</th>
        <th>Name</th>
        <th>Birthdate</th>
    </tr>
    <c:forEach items="${users}" var="user">
        <tr>
            <td>${user.id}</td>
            <td><c:out value="${user.name}" /></td>
            <td><fmt:formatDate value="${user.birthdate}" pattern="yyyy-MM-dd" /></td>
        </tr>
    </c:forEach>
</table>

Does it make sense? You see, it's kind of a convention which you can use everywhere to store, transfer and access data.

See also:

• JavaBeans specification

---

Beans themselves

JavaBeans are everywhere, they're a convention and just about every single slightly larger library out there uses those conventions to automate things. Just a few reasons why JavaBeans should be used:

• They serialize nicely.
• Can be instantiated using reflection.
• Can otherwise be controlled using reflection very easily.
• Good for encapsulating actual data from business code.
• Common conventions mean anyone can use your beans AND YOU CAN USE EVERYONE ELSE'S BEANS without any kind of documentation/manual easily and in consistent manner.
• Very close to POJOs which actually means even more interoperability between distinct parts of the system.

Also there's of course Enterprise JavaBeans which are a whole another matter and shouldn't be mixed with plain JavaBeans. I just wanted to mention EJB:s because the names are similar and it's easy to get those two confused.

Beans in web applications

If you consider "normal" JavaBeans in web app context, they make more sense than wearing shoes in your legs. Since the Servlet specification requires for sessions to be serializable, it means you should store your data in session as something that's serializable - why not make it a bean then! Just throw your SomeBusinessDataBean into the session and you're good to go, laughably easy, specification-compliant and convenient.

Also transferring that data around the application is easy too since JavaBeans help you to decouple parts of your application completely. Think JavaBeans as a letter and various subsystems of the application as departments within a very large corporation: Dept.A mails a bunch of data to Dept.B, Dept.B doesn't know -or even care- where the data came from just as it should be and can just open the letter, read stuff from it and do its thing based on that data.

Beans in standalone applications

Actually what's above applies to standalone apps too, the only difference is that you can mess up with the UI a bit more since standalone applications have stateful UI:s while web applications have statelss UI:s which in some cases only simulate stateful UI:s. Because of this difference, it's easier to make a mess with standalone application but that's worth a whole another topic and isn't directly related to JavaBeans at all.

---

A bean is nothing much, really. For a class to be a "bean", all it requires is:

• to have a public, no argument constructor
• to be serializable (to implement the Serializable interface, either directly or through one of its super classes).

To that, you can add getters and setters for properties of the class that conform to a specific naming convention if you want the fields to be discoverable in certain circumstances (e.g. making that class some object you can drag and drop from a visual editor in your IDE, for example).

You can find more directly from Sun here.

---

A Java Bean is a software component that has been designed to be reusable in a variety of different environments. There is no restriction on the capability of a Bean. It may perform a simple function, such as checking the spelling of a document, or a complex function, such as forecasting the performance of a stock portfolio. A Bean may be visible to an end user. One example of this is a button on a graphical user interface. A Bean may also be invisible to a user. Software to decode a stream of multimedia information in real time is an example of this type of building block. Finally, a Bean may be designed to work autonomously on a user's workstation or to work in cooperation with a set of other distributed components. Software to generate a pie chart from a set of data points is an example of a Bean that can execute locally. However, a Bean that provides real-time price information from a stock or commodities exchange would need to work in cooperation with other distributed software to obtain its data.

We will see shortly what specific changes a software developer must make to a class so that it is usable as a Java Bean. However, one of the goals of the Java designers was to make it easy to use this technology. Therefore, the code changes are minimal.

Advantages of Java Beans

A software component architecture provides standard mechanisms to deal with software building blocks. The following list enumerates some of the specific benefits that Java technology provides for a component developer:

• A Bean obtains all the benefits of Java's "write-once, run-anywhere" paradigm.
• The properties, events, and methods of a Bean that are exposed to an application builder tool can be controlled.
• A Bean may be designed to operate correctly in different locales, which makes it useful in global markets.
• Auxiliary software can be provided to help a person configure a Bean. This software is only needed when the design-time parameters for that component are being set. It does not need to be included in the run-time environment.
• The configuration settings of a Bean can be saved in persistent storage and restored at a later time.
• A Bean may register to receive events from other objects and can generate events that are sent to other objects.

Here's a simple example of a Javabean:

public class MyBean implements java.io.Serializable
{

       protected  int theValue;

       public MyBean()
       {
       }

       public void setMyValue(int newValue)
       {
           theValue = newValue;
       }

      public int getMyValue()
      {
           return theValue;
      }

}

This is a real Bean named MyBean that has state (the variable theValue) that will automatically be saved and restored by the JavaBeans persistence mechanism, and it has a property named MyValue that is usable by a visual programming environment. This Bean doesn't have any visual representation, but that isn't a requirement for a JavaBean component.

참고URL : https://stackoverflow.com/questions/1727603/places-where-javabeans-are-used