Page History
...
To revise this layer two J2EE patterns have been used: Session Facade and Application Service.
Model objects have now only attributes, and no behaviour: the only methods are setter/getter ones. A model object knows its relations with its fathers and its children: e.g. a collection keeps a list of all the community it belongs to and all the items it owns.
!DataModel.png_! 
Logic is now owned only by managers, no more logic owned by DAOs. The old managers have been invested with more responsabilities, and new managers with specific purposes have been created.
These are some important changes:
- ArchiveManager has now the responsability of managing Community, Collection and Item: it manages links between these objects, creates and removes them. It keeps all the old functionalities.
- ItemManager is a new manager: it manages the internal part of an item, bundles and bitstreams.
- AccountManager manages EPerson and Group: creations and removals, plus some method for InProgressSubmission objects. Old responsabilities are kept.
The Dspace Public API are now only methods of the managers.
To create model objects, factory classes have been introduced: to create, eg, a Collection, ArchiveManager invokes CollectionFactory (no more dao.create)
!CreateCollection.png_!
It's important to notice the separation between the creation of a Java object and its persistent representation in the DB: managers and factories works only on the object, and do not know anything about persistent fields. The Business Logic Layer doesn't know how CRUD operations against the db are performed.
To manage persistence, in the managers' point of view, there is an appropriate class, ApplicationService. ApplicationService is a manager that performs persistence operations, it offers "find" and "findAll" methods, and other ones to perform CRUD operations. When a manager needs to save (persist) an object, it will call the save() method of ApplicationService, from the point of view of the Business Logic Layer, DAO objects do not exist, there's only a manager for persistence. ApplicationService is therefore an interface between Business Logic Layer and Storage Layer, and its methods represent the Storage API.
...
Storage Layer have been revised using Domain Store pattern. This layer is now totally transparent, because the other layers know only its interface, ApplicationService class. !NewStorageLayer.png_! To 
To implement Domain Store, Java Persistence (JPA) has been used, with Hibernate as JPA Engine. All model objects have been mapped with JPA Annotations: grounding on these mappings, the DB Schema is automatically generated, there are no DBMS-specifical directives. Only standard JPA annotations have been used, so it's really easy to change JPA-Engine (e.g. TopLink).
Simple CRUD operations are responsability of JPA's EntityManager, while research operations and complex queries are performed by DAOs: DAO objects have now no logic, they perform only queries to "access the data".
The methods of ApplicationService just call EntityManager or a particular DAO.
...
What follows is a high-level view of the architecture of the prototype:
Current status
...
Overview
Content Tools