cancel
Showing results for 
Search instead for 
Did you mean: 

Advantage of model relations?

Former Member
0 Kudos

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

Accepted Solutions (1)

Accepted Solutions (1)

Former Member
0 Kudos

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

Former Member
0 Kudos

Hi Abhijith,

thank you for your answer. If I understand you right, you recommend not to use model relations. But I'm still looking for arguments of the usage of model relations.

Regards,

Marc

Former Member
0 Kudos

Hi Marc,

Am recommending to use model relations. am a follower of model relations, you must split your app as much as possible, you must split into different java bean class, and other model classes, you must split each and every of your logics into seperate methods, that is the standard way of coding, by doing so you can maintain your access restrictions properly, if not use different models your private elements can be read by any code snippet of your class. If you do not use models you are violating the rules of object oriented language

please read more about javabean model with some good material

Regards

Abhijith YS

Former Member
0 Kudos

Hi Abhijith,

I can't really understand your answer. I know the advantages of using java bean models and I'm also familar with OO programming. But that was not the question!

I'm only looking for the advantage of defining model relations instead of rebuilding the structure during context binding.

Regards,

Marc

Answers (0)