A common strategy to shield the presentation tier from the persistence tier is to model the services in between, they will be used to implement the business logic in the application tier. The technology behind is of little interest to the developer (that's one of the good points of MDA right!), but it's good to know Spring POJOs are being used (optionally wrapped with EJBs: more specifically EJB Session Beans).
In order to model such services you would just create another class, but this time you will give this class the <<Service>> stereotype.
Generally speaking it is sufficient to only model operations in these services, they represent the operations that can be called remotely, consider these operations the API of your application's back-end.
Notice how we have modeled dependencies from the service to the entities, this will render accessors to the DAOs of both entities in the service. You will need to draw such dependencies when you need access to the persistent storage of entities. This is similar to the dependencies drawn between entities, as we have seen before.
Car.hbm.xml
Car.java
CarImpl.java
CarDao.java
CarDaoBase.java
CarDaoImpl.java
Person.hbm.xml
Person.java
PersonImpl.java
PersonDao.java
PersonDaoBase.java
PersonDaoImpl.java
RentalService.java
RentalServiceBase.java
RentalServiceImpl.java
ejb/RentalService.java
ejb/RentalServiceBean.java
ejb/RentalServiceHome.java
There are a few other things you can do with these services, these features will be presented in the sections ahead.
If you want an operation to have a parameter which is allowed to be null
then simply
assign the <<Nullable>> stereotype to that parameter.
In the next section we'll learn about value-objects, click here to continue.