Learning notes for J2EE Design patterns -- using entity components for data access

1. The entity component is only one of the implementation options in the EJB layer. Entity components should not be exposed to customer software. The WEB layer and other EJB client software should never directly access entity components. It should only deal with a session component layer composed of session components that implement application business logic. This not only maintains the flexibility in application design and implementation, but also often improves the performance.
2. It is recommended that the session component only access the object component through a persistent facade of the common JAVA Data Access interface. Although the entity component implements a special data processing method, the standard JAVA interface does not. This approach does not maintain flexibility, but also proactively tests an application. I have a lot of doubts about the future of object components, because JDO can provide a simpler, more common, and better performance solution wherever entity components are applicable. By using DAO, we still have the ability to replace JDO or any other persistence policy, even after an application is implemented by using an entity component from the very beginning.
3. An object component is usually a thin layer used to embody a data storage that is not based on objects. This thin layer is not required if a data storage like ODBMS is used for objects, because the helper class can be used to access this data storage from the session component.
4. There are two arguments about the entity component: 1) granularity of the entity component and 2) whether the entity component can implement the business logic.
5. A rough object may model a logical record, which is distributed in multiple tables. A fine granularity may be mapped to a single table; in EJB2.0 CMP, fine granularity is generally considered more convenient. Although coarse-granularity modeling is more conducive to object-oriented design, there is a conclusion:
In EJB2.0, it is better to use the CMP to apply object components to very fine-grained objects.
6. The following conventions cannot be broken for any reason:
Only the persistence logic is implemented in the entity component. Do not implement the business logic!
7. The "N + 1" problem of BMP. For the find method of BMP, the implementation of it in EJB needs to return the primary key set. What has BMP done behind the scenes?
If you want to select all the personnel information of a city, BMP executes n + 1 queries (n indicates the record to be found)
Select pk, NAME, from users where pk =
...
Select pk, NAME, from users where pk =
It would be nice if you want to query a small number of records. Unfortunately, if you query a large number of records, such as 5000, this should be a normal query for a system with 3 million users, so BMP will automatically execute 5001 similar queries. Any proper implementation method should be similar to the following statement:
Select pk, NAME, FROM USERS WHERE PK IN
Conclusion: Do not use BMP in entity components, but use persistence from stateless session components. Compared to executing data access from a DAO layer, using BMP does not add much value, but increases complexity.
8. CMP2.0 introduces the main business method (I usually call the home method). Each entity has its own business method (the method defined in the remote interface). Both can call ejbSelect () methods to obtain the logical operations you want to perform. Of course, you can also perform any other operations, such as calling stored procedures.
9. DAO should be used to separate data access and business logic. Of course, DAO can be implemented using stateless session BEAN.
To be continued