Advantage of model relations?

Question

Hi,
we are using Java Bean models for our web dynpro project. Therefore we generated a model of type "Java Bean model". In the import dialog of the model generation we detected the possibility to define model relations according to the relations used in our java beans. We ended up with a huge model with several model classes. Everything looks fine but I'm seriously asking myself what the big advantage of this approach is. Asuming that the Java bean model will change sometimes I have to reimport the model and have to define all these relations by hand again! So I don't really see an advantage but I guess that I have lost sight of advantages.
I really would appreciate any replies showing me the advantages. Maybe there are also helpful documents.
Regards,
Marc

Answer 1

Hi
JavaBean model allows us to introduce an additional layer of abstraction that has some great benefits like hiding the underlying service, improves availability and performance
Advantages :
1 . Its a Structured and Standard way of coding.
2 . Its Easy for coding and maintaining and enhancements.
As heavy calculations are involved with your application from a long time view its better you go for using seperate bean for this case
1 . /message/1308247#1308247 [original link is broken]
<b>Compact and Easy</b>JavaBeans components are simple to create and easy to use. This is an important goal of the JavaBeans architecture. It doesn't take very much to write a simple Bean, and such a Bean is lightweight&#63719;it doesn't have to carry around a lot of inherited baggage just to support the Beans environment. If a Bean does not require the advanced features of the architecture, it doesn't get them, nor does it get the code that goes with them. This is an important concept. The JavaBeans architecture scales upward in complexity, not downward like other component models. This means it really is easy to create a simple Bean. (The previous example shows just how simple a Bean can be.)
<b>Portable</b>
Since JavaBeans components are built purely in Java, they are fully portable to any platform that supports the Java run-time environment. All platform specifics, as well as support for JavaBeans, are implemented by the Java virtual machine. You can be sure that when you develop a component using JavaBeans it will be usable on all of the platforms that support Java (version 1.1 and beyond). These range from workstation applications and web browsers to servers, and even to devices such as PDAs and set-top boxes.
<b>Leverages the Strengths of the Java Platform</b>
JavaBeans uses the existing Java class discovery mechanism. This means that there isn't some new complicated mechanism for registering components with the run-time system.
As shown in the earlier code example, Beans are lightweight components that are easy to understand. Building a Bean doesn't require the use of complex extensions to the environment. Many of the Java supporting classes are Beans, such as the windowing components found in java.awt.
The Java class libraries provide a rich set of default behaviors for components. Use of Java Object Serialization is one example&#63719;a component can support the persistence model by implementing the java.io.Serializable interface. By conforming to a simple set of design patterns (discussed later in this chapter), you can expose properties without doing anything more than coding them in a particular style.
<b>Flexible Build-Time Component Editors</b>
Developers are free to create their own custom property sheets and editors for use with their components if the defaults aren't appropriate for a particular component. It's possible to create elaborate property editors for changing the value of specific properties, as well as create sophisticated property sheets to house those editors.
Imagine that you have created a Sound class that is capable of playing various sound format files. You could create a custom property editor for this class that listed all of the known system sounds in a list. If you have created a specialized color type called PrimaryColor, you could create a color picker class to be used as the property editor for PrimaryColor that presented only primary colors as choices.
The JavaBeans architecture also allows you to associate a custom editor with your component. If the task of setting the property values and behaviors of your component is complicated, it may be useful to create a component wizard that guides the user through the steps. The size and complexity of your component editor is entirely up to you.
Regards
Abhijith YS