Differences between data object's field and Java Bean property
In the Fishbolt data model, a data field is presented by the IDataField<T>
interface. Its generic parameter T
defines the type of a data field value. The IDataField
interface declares setValue
and getValue
methods which are used to set and get the value of a data field, respectively. For example, a data field with an Integer
value is presented by the IDataField<Integer>
interface whose setter and getter methods are used to set and get an Integer
value.
The life cycle of an IDataField
instance is the same as the life cycle of its enclosing IDataObject
instance. The value of a data field can be changed many times during its life cycle. But the data field instance itself will remain the same.
A data field is declared in a data object as a constant, for example:
final static FieldDeclaration<String> name = new FieldDeclaration<String>();
Assuming that our data object is called Department
, we can make a static reference to the data field in our code using this constant: Department.name
. The constant declaration defines existence of the data field (IDataField
instance) in the data object instance of the corresponding type. The constant is used to access the value of the corresponding data field. The base data object interface called IDataObject
declares the following method:
<T> IDataField<T> getDataField(FieldDeclaration<<wbr>T> declaration);
The code to access the value of the data field presented by the name
constant of the Department
object is shown below:
Department d = ...;
IDataField<String> dataField = d.getDataField(Depatment.name)<wbr>;
String name = dataField.getValue();
Or you can use a shortcut method of the ModelUtil
class to get the data field value as shown below:
String name = ModelUtil.getValue(d,Depatment.name);
In contrast to the Fishbolt data model, the Java beans-based approach doesn’t involve a separate class for a Java bean property. In other words, Java beans do not provide an object that wraps up a property value and has the same life cycle as a bean instance. Such an object may be implicitly present in developer’s mind as a property name – Java bean instance pair. But the presence of such an object in developer’s mind doesn’t allow the developer to make a reference to this object in program code.
Of course, the developer can easily create a class defining the property name – Java bean instance pair. But there is a price to pay for it because such a class will make it much more expensive to change the property name or to delete the property. In program code, it's impossible to make a reference to a bean property in such a way that reference-related errors occurring as a result of deleting the property or changing its name can be detected at compile-time. (The errors became apparent only at runtime.) The reason behind the problem is that a bean property can be only referenced using a String
that specifies the name of the property.
You may ask: is an object-wrapper for a field value really needed? A strong argument against effectiveness of these wrappers is that they require extra memory comparing with Java beans. But the advantages of the Fishbolt data model outweigh this shortcoming. The model provides a self-descriptive and simple way of presenting a data unit (i.e. a field value) and allows users to create a variety of reusable components for data handling. With the model, it's possible to make a reference (via a static constant) to a data field before an instance of its enclosing data object is created (constants like Depatment.name
don’t require for an instance of a data object to exist). This possibility allows creating whole systems that will be configured by declaring a set of constants, with correctness of references in program code being checked at compile-time.
As an example of such a system, see the "User interface for the data model in Eclipse IDE" project (http://fishbolt.org/eclipse/org.fishbolt.model.eclipse/doc/plugin.article.en.html). In this project, data is bound to components of the user interface in a declarative way as described above.
good articles, look deeply while feel free
分享到:
相关推荐
18. Differences Between LiDAR and Field Based Slopes (5, 10,20 meters) 44 19. Relationship of Water Surfaces to LiDAR Point Density 47 20. Marmot Dam: Orthophotographyand Colorized Slope Model 50 21. ...
Appendix A Differences between MASM 6.0 and 5.1 Appendix B BNF Grammar Appendix C Generating and Reading Assembly Listings Appendix D MASM Reserved Words Appendix E Default Segment Names Appendix F ...
For example, if T1 writes some object that is in T2’s input or output set, there is a dependency between T1 and T2. Bad Dependencies These include lost updates, dirty reads, non-repeatable reads, ...
- **Advanced Web Parts:** Connectable Web Parts support data connectivity between web parts and can be enhanced with AJAX support. - **Silverlight and External Applications:** Describes how to ...
72123 Spacing Between Data Packet Header and Data Packet Payload7-10 722 Link Commands7-10 7221 Link Command Structure 7-10 7222 Link Command Word Definition 7-11 7223 Link Command Placement 7-14 723 ...
Fetching a Row as an Object 10.3. Zend_Db_Profiler 10.3.1. Introduction 10.3.2. Using the Profiler 10.3.3. Advanced Profiler Usage 10.3.3.1. Filter by query elapsed time 10.3.3.2. Filter by ...
3.4 User Data Manager (Dealing with Player Stats Such as Health, Lives, etc.)....37 3.4.1 Script Breakdown..........................................39 4. Recipes: Common Components 41 4.1 Introduction...
Much faster processing due to linking to Zlib object files for compression and decompression routines. Blocked Zip Files (spanned zip archives split onto hard drive) - Now completely compatible ...