-
Notifications
You must be signed in to change notification settings - Fork 2
Architecture Model
We used an MVC design with the persistence portion represented by the “model”, the back-end portion (including service and controller methods) represented by the “controller”, and the front-end represented by the “view”. The user interacts with the application front-end (via the website or the app), with the front-end showing them different functionalities depending on the type of user. The front-end then sends the user requests to the backend, which is split into two layers: the controller package and the service class. The controller interprets the request and calls the appropriate service method(s). The service then makes a request with the data access objects, which then updates or retrieves information from the database, depending on the request. Updates from the database are then sent back up the pipeline to update what the user sees. Note that we did not use any external subsystems so we do not have any in our model.
This portion is split up into the website and the app, with the app having fewer features. The different types of users (not signed-in, patron, librarian, and head-librarian) are able to access different features. Features that are available to the user are made clear via the navigation menu that is centered towards the top of the page. When not signed in, a user can browse the items and rooms available to be booked, as well as the operating hours of the library. In addition to those features, a patron is able to make reservations for items and rooms, and change their account info. A librarian, meanwhile, can view each other’s shifts, check out or reserve items for patrons, modify patron accounts, and add items and rooms to the database. The head-librarian has the added ability to add and remove librarians from the system (i.e. hire and fire them), modify their shifts, and modify the library operating hours.
This portion comprises the controller and service packages, which together handle front-end requests and the business logic of the application. The controller and service packages have three main groupings: one for items, one for users, and one for time slots. With the exception of the rooms, which are programmed similar to items in the back-end, the main grouping in our model includes all of our controller and service packages.
This portion includes the data access objects (DAOs) as well as the database itself. Create, retrieve, update, and delete requests are sent from the service package to the DAOs, which then communicate with the database to perform the requested action and provide the requested information to the service package.