JDO vs entity Beans: a kind advice
Two years ago, Sun proposed EJB1.1 norms, which is a historical innovation for enterprise-class calculations. However, its defects are also self-evident. In many ways, his remote interface calls very slowly and created a smoot-grained object.
Thereafter, JDO appeared again, which is a new way to store objects in the database, which can replace EJB entity Beans in many places. It seems that JDO is a solution to the problem of entity beans. In most applications, the database's operation is basically the value of queries and update fields. Many JSP only require simple display and modification, so the remote interface of EJB has become a huge overhead; the remote getter and setter methods are also unnecessary, especially if you have the same Getter method in duplicate calls. time. Therefore, if the data can be operated on the client and then send the result at a time, it should be more reasonable.
JDO recognizes this. In fact, it can be seen as an object-oriented JDBC interface. For many developers, it can be said to be a good solution, but it also has insufficient.
EJB entity Beans real advantages lies in the business logic of the server, while JDO is not, because JDO is for the client. But if you want to understand this is not easy, because the current object-oriented design pattern of EJB is very small. There is no ready-made method or inheritance. However, we can try to imagine EJBs to fully implement object-oriented (actually this is not easy to do, may take a long time to complete). Then, the server's business logic will become the weight of the application design. For example, we have a custom Customer entity, which has a method getCreditLimit () method, which can be extended by different Customers. This will use these entity Beans to create a completely object-oriented application architecture. So what is the way to make EJB Get-SET operation more efficient?
Improvement of EJB interface
The concept of dependent objects is introduced in EJB 2.0. It improves the EJB's execution efficiency, but it is not very perfect. Therefore, the object cannot be processed as a dependent object when designing. Because an object is in processing, it must be an entity; this can only display a localized copy of the entity, then use this interface to store data:
Interface Emodel Extends
PossiblySomekindofResultsetnaVigationinteface ??? {
setfield1 ();
Getfield1 ();
}
Below is an entity bean interface:
Interface Eremote Extends ejbobject {
SetField1 (); // Method in Emodel
Getfield1 ();
Emodel getModel ();
Void SetModel (Emodel)
Void dosomeserversidebusiness ();
}
If we just want to get a data object (assuming that Emodel can operate EJB handle via an ID) The HOME interface can contain a specific Findl Model method to get an entity object. Similarly, we can also define more methods to operate EJB. For example, the following method obtains the desired serialized object by incoming Getter or Setter:
Object GetModelwith (Object Modelgetter,
Object getTerhintsormapper;
Void SetModelwith (Object Modeltoseet,
Object ModelSetter, Object SetTerhintsormapper;
Such a design can give us a great flexibility to our design. We can extend our EJB containers in the form of plugins to implement mapping XML, JDO, or SQL query results set. These extensions can be done by developers, of course, can also accomplish these jobs, such as Castor. This allows you to control a lot of XML messages. For example, an entity bean responsible for the development of goods can control a lot of shipping form XML messages. Developers from non-use server providers can use the interfaces described above. If the above interface is implemented by the application server provider, the process of this mapping can be changed. If the container provides some standard API, it will make the run faster. For example, a database service provider can generate and run SQL through an XML message.
Similarly, when using the Finder method in the EJB, the program may be able to determine what information needs to be required: Is an entity object or a data? And the Finder method can also achieve a mechanism, which can receive a query from the client in the case where the data connection has been closed. In addition, the data is filtered through this mechanism, for example, the Finder method in the EJB is the entire conformational object set, but maybe we just want to get the result set of a field, then you can pass this Methods to filter data for data.
An organization of IBM in San Francisco has achieved a similar architecture. Which object cannot be modified by a specific processing division model. Then as long as the client is running, we can receive, copy or operate data locally.
