CS636 Class 6  

Resource: DAO API

Why two POJOs, PizzaOrder in domain and PizzaOrderData in service?

There is another POJO in the system, in the service package, named PizzaOrderData. It’s there because PizzaOrder, being mutable, shouldn’t be returned to the presentation layer—that code should not be tempted to mark a pizza order « baked »--that can only happen in the service layer, the core of the app. 

PizzaOrderData has all the data from PizzaOrder, but has no mutator methods at all, so represents a PizzaOrder at a certain time, and, being invariant, can be returned to the presentation layer. This kind of derived object is sometimes called a transfer object.  It doesn’t deserve to be in the domain package, because it’s not the working representation of the order—that’s PizzaOrder.  It just passively carries its data into the presentation in a safe sealed-up package.

Mutable and Invariant Domain Objects
We see that there are two kinds of domain objects, invariant ones like Topping that can be returned to the presentation layer as well as be involved in the core app service layer, and mutable ones like PizzaOrder, which should have associated invariant transfer objects like PizzaOrderData to use for providing the presentation layer with needed data.

DAO API for pizza1: look at DAO API, see a lot of DAO calls. Let’s concentrate on the ones that correspond to the student-related service calls in the service API we looked at last time. Best to do the fing/grep yourself: "cd $cs636/pizza1/src/cs636/pizza/service", then "grep public *DAO.java"

Note: use of TreeSet is somewhat unusual, because it requires the domain class Topping to implement Comparable (see method compareTo in Topping). HashSet could be used here without that requirement. It has the advantage of showing topping names in alphabetical order.

Service Calls and how they use DAO calls: look at code online

makeOrder

• looks up current day using findCurrentDay()    of AdminDAO  
• calls insertOrder(PizzaOrder order) of PizzaOrderDAO

getToppingNames: returns Topping names to presentation

• calls findMenuToppings of MenuDAO, a DAO “finder”, returns MenuTopping object

getOrderStatus: returns PizzaOrderData objects built from PizzaOrder objects

• findOrderByRoom( - - ), a DAO “finder”, returns PizzaOrder objects

More on DAO APIs: DAO’s have convention/pattern

CRUD API:
Create   Retrieve   Update   Delete

In the calls we see
studentService.makeOrder(...) in presentation code
pizzaOrderDAO.insertOrder(...) in service code

These are method calls down through the layers of the software.

• studentService is an object reference to an instance of class StudentService
• makeOrder is a method of class StudentService

so studentService.makeOrder(...) is how you  call that method of that class.

Now somewhere, sometime, the StudentService object was created:
StudentService studentService = new StudentService(...);
but we haven't yet seen that part.

Here is a bit of StudentService.java:

package cs636.pizza.service;
import...

public class StudentService {
    private PizzaOrderDAO pizzaOrderDAO;   <---field: a ref to PizzaOrderDAO object
    private MenuDAO menuDAO;
    private AdminDAO adminDAO;

    public StudentService(PizzaOrderDAO pizzaDAO, MenuDAO mDAO, AdminDAO admDAO) {  <--constructor
        pizzaOrderDAO = pizzaDAO;
        menuDAO = mDAO;
        adminDAO = admDAO;
    }

    public Set<String> getSizeNames()throws ServiceException  <-- method of StudentService
    {
        Set<MenuSize> sizes = null;
        try {
            sizes = menuDAO.findMenuSizes();  <-- call down to MenuDAO
        } catch(SQLException e) {
            throw new ServiceException("Can't access pizza sizes in db: ", e);
        }
...

Somewhere the constructor is called, creating one instance of StudentService. We only need one of these objects, so it will be a "singleton".
A singleton is just the one and only object created from a class, in cases where multiple objects are not needed.
Similarly, we will use singletons for AdminService, and each of the DAO classes.

Nest: How these singletons are related, and how they are created.