An EJB Design Mode is recommended.

/**
* This article has moved from the heavy particle space, and has been approved by the original author.
* Before reading this article, read Sun's article.
* Http://developer.java.sun.com/developer/technicalArticles/ebeans/ejbperformance/
*/
// ------------------------------------------ Original Text
Haha, I will try it. My presentation and organizational skills are not very good ^ o ^
--------------------------------------------------------------------------------
[Honest Monk] added to the space of heavy particles at 10:09:07
/**
* If I forget it for a while, I may not, because after all, I have done too much, but I can write it, but I can think more clearly, but because of the invitation of heavy particles
*/
Here it must be EntityBean [BMP or CMP is feasible, because it does not discuss how EntityBean actually implements this layer, but how it targets its Client (generally application, javaBean, etc.) and how to use it for its client]
ASIDE: I did not expect any other benefits, which is beyond the benefits described in the above article. This is why I recommend it.
The above article introduces three modes
First mode [Using Separate Methods to Access Individual Attributes]
Needless to say, an EntityBean seems free after you get a Remote Interface, but for example, your EntityBean has 30 fields/attributes, if you want to update 18 fields (which is common to me), you have to use your Remote. setXXX () 18 times, this is 18 times of remote access, unless you are sure that your client and your server are in the same container, otherwise, even if your client and your EntityBean are on the same machine and in the same application, it is also RemoteCall, because for container, it is Remote, according to sun, remote Call is expensive, which will increase the burden on your server.
This mode also has the second more serious drawback, that is, Transaction cannot be guaranteed. In a method of your client, Remote. setXXX () 18 times, any of which can be interrupted due to an error (for example, your data is too long ...), However, you cannot guarantee its transaction Rollback unless you hand-written the Code to ensure that, if you do so, I think bea's people will cry, it's $20000, therefore, it is not advisable to write transaction on the clien end.
So how can we solve it? The second mode is Using a Value Object for All Attributes.
Abstract all fields into an object
Describe it in one sentence. In the previous mode, you set your attributes to EntityBean 18 times on your client side, in this mode, you set all your attributes (30 types) on your client first, A Model has been constructed (it is a common class abstracted by your EntityBean. If you do not understand it, you should understand it after reading the article ), on your client, you only need to call a Remote method, such as Remote. updateMember (Model myModel) is a complete object instead of an attribute. In other words, it is "package upload" ^ o ^, the performance benefits will not be mentioned. For more information about the specific implementation, see the article.