Database apps including UI (user interface): we will cover line-oriented and web UI (browser on client).
Databases handle long-term data for dynamic websites all over the world.
Prereq: CS430/630 or equivalent database background, CS310 or Java including Collection classes such as HashMap and TreeSet
Useful: HTML, XML, JUnit, ant, but will cover these.
If your Java isn't strong, consider taking cs637 next term, just as useful as a prerequisite to cs680. See comparison grid cs636/cs637 on class web page.
Look at syllabus. Collect student-info sheets.
Be sure to get a UNIX/Linux account for cs636 by Friday, 9/9, to list your username for the needed Oracle and mysql accounts, and access to topcat.cs.umb.edu.
Assignments: hw, programming projects, by pairs later on.
hw1 due Mon, 9/19 is available—see link from the class web page at www.cs.umb.edu/cs636.
Class project on music store from Murach’s text. See pg. 664 for non-portable SQL for tables. Challenge: see if you can make it portable.
Reading: Murach, Chap. 1. You could also start reading Chap. 11-12 on databases (specifically MySql), starting at pg. 364. I’ll create a mysql database for you using mysql on topcat.cs.umb.edu. We’ll also use Oracle.
1. Development Tools
Java, Eclipse, Ant
Develop on PC, deliver on Linux
Eclipse has built-in help. We'll cover ant soon.
See dev setup instructions linked to class web page www.cs.umb.edu/cs636. Try this by Monday. Also apply for UNIX account.
TDD Test-Driven Development
--Tests First or Very soon
- we will use JUnit for unit testing
Inversion of Control “Hollywood Principle”
--don’t call us, we’ll call you
-- Each object should only passively accept references to other objects, not itself create a dependent object.
---> good software, better testingDetails: Problem with creation of a dependent object:
Idea of enterprise development—serious programming efforts, lasting years we hope, maintainable.
Involving different kinds of people: artistic types, programmers, etc.
3. Client Server vs. Web-based Architecture
Note that the JDBC connection is relatively long-lived here, usually lasting the whole time the client is running.
4. Web-based (Browser as Universal User Interface) See Murach, pp. 6-11
HTTP over TCP/IP is used between the browser and the web server.
The web server program hands off the request to the web app, which runs on the same system as the web server. The web app makes a JDBC connection (over TCP/IP) to the database, which may be running on the same computer system as the web server, or on another computer. (In fact, the web server and web app may share a single process.)
The JDBC connections are short-lived, lasting only for one HTTP request cycle. But really, they are being “borrowed” from a pool of live connections and used for the short time. More on this later.
Software architecture of all apps for this course: three layers--
This important picture corresponds to the figure on p. 17 of Murach, Figure 1-7. The presentation code calls the service layer code, the service layer code calls the data access code. The data access code uses JDBC to talk to the database. Then data is returned by the calls up the layers.Note that Figure 1-7 does not make clear that the domain objects can move between layers, so it’s a good idea to add the up-and-down arrow as in the above picture to Figure 1-7 to emphasize this important fact. In fact, we don't want all the domain objects to reach into the presentation layer, as we will discuss.
Idea of impedance mismatch: Java objects vs. database tables
In Java, we use graphs of objects. In the database, we use tables, a different way to hold data. How can we hold object data in the database?Simple case: no problem. For Employee objects and employees table, each Java object has one row in the table.
More complicated case: a Pizza object has a Set<PizzaTopping> to describe its toppings. So one pizza can have many toppings. Also, one topping can be used in several different pizzas. What database tables are needed?Consider this as modeled as a N-N relationship. Then, in addition to tables pizza and topping, we need a relationship table holding the relationship instances, for ex., (p01, t01) to express the fact that topping t01 belongs to pizza p01. (Actually we'll use a different setup.)
Pizza Objects vs. DB Entities Intro Example: More Details
Last time: First the simple case, where one table row corresponded to one Java object.
For example, suppose everything we need to know about an employee is held in one employee row: name, address, id, salary
DB: employees table (or employee table)
Java: Employee object, with fields for name, address, id, and salary.
Then the DAO layer just reads a row, creates an Employee object and sends it up the layers.
Similarly, the app may decide to create a new employee, so creates a new Employee object. (Remember, the heart of the app is in Java)
Then the DAO layer accepts the Employee object, and does a DB insert into the employees table.
But it can be more complicated---Java objects often come in object graphs, that is, objects with references to other objects, so they make a logical group.
Example of PizzaOrder with multiple Topping objects hanging off of it.
Not reached in class: How to set up a PizzaOrder object with multiple Topping objects.
In terms of Java objects, we would have a Pizza object with a field of type List<Topping> or Set<Topping>. A Topping could have a Set<PizzaOrder>, but if the app doesn’t ever need the pizzas with a certain Topping, there would be no such field. Either way, there is no app object needed for the relationship instances (like the fact that pizza p01 has topping t01), so there are 3 tables but only two Java classes (written for this app) for the Pizza-Topping situation.
Also, we will use PizzaTopping as the class name for topping objects.
Note this use of List<PizzaTopping> or Set<PizzaTopping>--we are using the Java Collection classes, reviewed in hw1. List and Set are interfaces, that is, just descriptions of methods without implementation. But the JDK also has concrete classes, implementations of these interfaces:
List<T> interface: implementations of List: LinkedList<T>, ArrayList<T>
Set<T> interface: implementations HashSet<T>, TreeSet<T>
Thus to set up a Set<PizzaTopping>: you need to use the concrete class’s constructor, then later use just the interface type for all but very special cases:
Set<PizzaTopping> toppings = new
HashSet<PizzaTopping>(); <--use concrete
class with “new”
PizzaTopping top1 = new PizzaTopping(“pepperoni”);
PizzaTopping top2 = new PizzaTopping(“mushrooms”);
for (PizzaTopping t:toppings) // iterate
through the Set (enhanced for loop)
System.out.println(“topping: “ + t);
The above set of toppings is a Set<PizzaTopping> separate from a PizzaOrder. To make it part of a PizzaOrder, we define a field (say toppings) of PizzaOrder of type Set<PizzaTopping>. Then each PizzaOrder object contains a Set<PizzaTopping> to describe its toppings. This gives us an example of an object graph, with many PizzaTopping objects referenced from one PizzaOrder object.