| |
| Separation of business logic and data access |
| |
|
An application consists of business logic and data.
|
| |
|
The framework knows a number of entities intended for storing data in the administrative field. These entities have been intended for the rise of documents, contacts, notes, dossiers and etcetera. Company logic contains managers for the data access of these entities. These managers offers services for adding, changing and deleting objects. These managers combine the different implementations of these managers company logic and data access. In the case that more complex company logic is specified, a stricter separation between company logic and data access is necessary.
|
| |
|
All managers in the framework exist from an interface and an implementation. The implementation can replace transparency by configuration. This way database specific problems are solved.
|
| |
|
Company logic and data access become implemented in the EJB container. This has been necessary for the use of distributed operations and other functionality by the container. Read data access actions, are carried out outside the EJB container, directly towards the source.
|
| |
| Back to architecture |
| |
 |
|
|
Framework
|
| |
|
Realise applications with an assembly process
|
|
|
|
