uPortal uses a very layered approach to data modeling, data storage and business logic. We refer to these layers as Domain Objects, Data Access Objects (DAOs), Registries, and Services. Each of these layers serves a specific role and as much as possible the roles should be kept distinct.

Domain Objects

Domain objects model the data that uPortal uses. Things like publishing portlets, preferences, user attributes, pretty much anything that is stored in the database is modeled as a Domain Object. Domain Objects should never have inherent behavior and only model data and the relationships between data.

Data Access Objects (DAOs)

Data Access Objects do just what they sound like they do, access data. DAOs act as the bridge between some persistent storage mechanism and the rest of uPortal for Domain Objects. DAOs should only ever provide the various CRUD style operations required when interacting with the persistent store, generally there is one each of create, update and delete methods along with any number of get methods to look up Domain Objects based on their various fields. No behavior or runtime dependencies (such as relying on classes from a ServletRequest) should be included in a DAO. They should work just as well from a command line tool as they do at runtime to simply access Domain Objects from the persistent store. In general the only two areas in uPortal that work directly with DAOs are the import/export tools and the Registries which apply buisiness logic to the domain object and persistence layers.

Registries

Registries add business logic to the data layer. Rules around when an object should be persistent versus transient, creating domain objects for a specific HttpServletRequest or other such behavior should all reside in the Registry layer. Some registries will be very simple, primarily passing through API calls to the DAO layer and it may seem pointless. The registry layer is VERY important however when considering future development. It keeps the DAOs focused on simply doing data access and consolidates the business logic for a domain in a single location.

Application and Service Layer

Services is a general term that applies to all of the runtime application level code. The portal rendering pipline, the implementation of the Pluto SPI, REST controllers that expose uPortal data are all considered part of the service layer. The service layer should take care to avoid implementing business logic and focus on their primary functional requirement, logic around how domain objects are accessed, stored or managed should all be at a lower layer by this point and high level functions such as registry.getEntityForUserAndLayoutNode(int userId, String layoutNodeId) should be in use to hide such re-usable logic from the service implementation.

Additional References

Having problems with these instructions?

Please send us feedback at uportal-user@lists.ja-sig.org

Browser not supported