1. The entity component is only one of the implementation seals in the EJB layer. Entity components should not be exposed to customer software. Web layers and other EJB client software should never access entity components directly. It should be derived from a session component layer that is configured by the session component that implements the application business logic. This not only maintains the flexibility in application design and implementation, but also improves performance.
2, the session component is preferably accessing the entity component only by a persistent facade of a normal Java data access interface. Although the physical component has a special data processing method, the standard Java interface is not. This approach is unflexible, and an application is also predictive. The author has a great doubt about the future of entity components, as anywhere in physical components, JDO can provide a simpler, more versatile solution. By using DAO, we still have the ability to exchange JDO or other persistent strategies, even after using entity components in the beginning, an application is implemented.
3, the physical assembly is usually a thin layer for embodying an object-based data memory. This thin layer is not required if a data store like an ODBMS is used because the assistant can be used to access this data store from the session component.
4. Two points on the debate of entity components: 1) The particle size of the solid assembly, II) whether the physical component can achieve business logic.
5, a crude entity may model a logical record, and this record is distributed in multiple tables; and a fine particle size may be mapped into a single table; in EJB2.0 CMP, it is usually considered more convenient. Although the modeling of coarse particle size is more focused on object-oriented design, there is a conclusion that in EJB 2.0, it is best to use CMP to use the CMP to use the entity component for a relatively fine object.
6, no matter what reasons can not undermine the following conventions: only persistence logic is realized in the physical component, do not implement business logic!
7, BMP "n 1" problem, for BMP's Find method, it needs to return to the primary key collection in EJB, what did BMP after the scene? If you want to select all the information of a city, the BMP will perform a query such as N 1 class (N represents the record that will be found) Select PK, Name,
From users where pk =
...
SELECT PK, NAME,
From users where pk =
If you want to check the quantity, it is better, unfortunately if you have a lot of records, such as 5000, this should be a normal query for a system that holds 3 million users, then BMP will automate 5001 Similar queries. And any legitimate method should be similar to the following statement:
SELECT PK, NAME,
From users where pk in
Conclusion: Do not use BMP in an entity component, and use persistence from stateless session components. With data access from a DAO layer, use BMP will not increase what value will only increase complexity.
8, CMP2.0 introduces the primary business method (I usually call Home method), each entity has its own business method (the method defined in the remote interface); both can be used to get the ejbselect () method Logic operations, of course, can also be used as any other operation, such as calling stored procedures, etc.
9, you should use DAO to separate data data access and business logic. Of course, DAO can be implemented with stateless session beans.
Last continued
