The Data Access Layer provides an API for accessing and manipulating data in the persistence tier and abstracts or hides much of this complexity from the session bean business logic tier. To find out more about the different tiers on an enterprise application and where DAO object typically fit in the stack, you can read the getting started guide.
For every entity class, modeled with the <<Entity>> stereotype, 3 DAO related objects are created. This provides the typical CRUD API and finder method accessability for a specific entity.
DAO's are just stateless session beans with a local interface. The presentation layer wouldn't use the DAO local interface directly. Instead, your session beans in the business layer would utilize the DAO interface for all persistence related tasks.
By modeling dependencies from the service to the entities the cartridge will inject the local interface of the DAO of the target entities in to the session bean. You are then free to use this DAO instance variable when CRUD features available in the API are required.
The following example, illustrates a typical entity POJO and its generated DAO components.
Since the Person entity contains finder methods, the PersonDaoImpl is generated once only to core/src/main/java. You can override or add any method implementation to this file.
The PersonDaoBase.java injects the javax.ejb.SessionContext by default and makes this available for use in the subclass via the context protected property. This base DAO class contains the bulk of the CRUD API implementation. It injects the default PersistenceContext and provides the finder method implementations modeled on the entity.
The Person entity contains the @NamedQueries annotation with the array of @NamedQuery annotations defining the query logic. The corresponding findBy methods in the PersonDaoBase provide the ability to either specify a query string or use the named query defined in the application at deploy-time.
The DAO stateless session bean is accessed via the local interface. This means that you cannot access DAO from a remote container, but this isn't a concern since your session facade exposes the remote interface and contains your business logic.
All DAO base abstract classes define the @TransactionAttribute annotation, setting the transaction type to REQUIRED. Typically, you would start your transactions in your business logic within your session facades.
The EJB3 cartridge provides the ability to set basic security constraints to allow role based security when accessing and invoking CRUD operations in the DAO session beans. To find out how to enable JAAS security, click on Security.
If you enable security and do not model actor dependencies on the entities to limit roles permitted to access your DAO, the EJB3 cartridge will add the @javax.annotation.security.PermitAll annotation at the class level of your base DAO class. This implies that all methods of the DAO are not checked for security constraints.
In the next section we'll learn about entity relationships, click here to continue.