In the previous installment of this series we completed our Model layer described in the Model-View-Controller (MVC) architecture. In that article we covered the façade (or service) layer:
- EmployeeCRUDFacade: A service layer class to handle data manipulation and data business rules for access by client code that should not work directly with the model layer.
Examples of data manipulation code and data business rule code include:
- Calculate the age of an employee. Your database holds a birthdate, but not an age.
- Calculate the number of years an employee has worked for your company. Your database holds a hire date but not a length of time.
- Calculate the number of approvals required for a time off request that exceeds a certain number of hours.
Examples of client code that should never access the model directly include:
- Workflow processing code.
- External system integration code.
- UI code (a managed bean…covered in this article).
It may appear on the initial design of an application that this layer is just adding extra code. In other words, why not just let my view bean access the DAO? Continue reading
In the previous installment of this series we began to build the Model layer described in the Model-View-Controller (MVC) architecture. In that article we covered low level database interaction classes as well as the representation of the data object for our sample Employee application. To recap, we designed the following classes four our Model layer:
- Employee: A base foundation class representing the employee data. The fields in this class, for our simple application, correspond to the fields on a Notes form.
- DominoEmplyeeDAO (and EmployeeDAO interface): The DominoEmplyeeDAO contains all of the code that processes the low level Domino database specific language for creating, reading, updating, and deleting an employee. The concrete class DominoEmployeeDAO implements the EmployeeDAO interface. The interface defines the generic method signatures that must be created by any class implementing that interface. This allows us to define a structured set of methods for working with any database without the requirement that client code have knowledge of the type of database implemented.
In a “real world” application there will be many “Employee” type Continue reading
In the previous installment of this series we described the object model that will be used to help illustrate the Model-View-Controller (MVC) architecture. Included in the article was an object diagram (not quite UML) which provided a representation of a very simple employee database application. To recap, the objects involved consist of:
- Employee object: This is our low level data. In Domino this comes from the data saved to a Domino employee document. In relational terms, this is a row of data.
- DominoEmployeeDAO (implements EmployeeDAO) : A Data Access Object (DAO) which provides a concrete implementation of an interface to the Employee data for a Domino database.
- DominoDB: These are the instructions for working with our Domino database. They are encapsulated by the DominoEmployeeDAO.
- EmployeeCRUDFacade: The business logic of retrieving data from the system.
In the previous installment of this series we introduced the idea of using standard Java development patterns for implementing your XPages project. The best practice of implementing the Model-View-Controller (MVC) architecture was described. To recap, the layers of MVC consist of:
Model: These are your Java objects that contain and manipulate the data from the database and implement business rules for managing that data
View: These are your presentation Java objects. Mostly (exceptions aside) these tends to be a one-to-one relationship between an XPage (graphical view) and a related view Bean.
Controller: This middle layer is the JSF API. No code is written here by the developer of JSF applications (including XPages). This is the FacesServlet.