Hibernate Client-server applications
Install hibernate_address and pizza2 on your development PC
and get them to work for Oracle and HSQLDB. Read the code.
Note that pizza2 and hibernate_address have build.xmls like
pizza1: first use the build.xml in the database directory to drop/load needed
database (you need to drop any old pizza1 databases first.) Then the build.xml
in the base directory is used to configure Hibernate with “ant config-oradb” or
“ant config-hsqldb”. Finally, “ant sysTest” executes the app using that
configuration. Note that the config step must be done with ant (or by manual
file copy). Once it’s configured, you can re-run it with Eclipse.
Here are some coding rules to set up client-server
applications using layering, applicable to pizza1 and pizza2. Let us know if
you disagree with any of the following:
The layers
1. System.in and System.out are
only for talking to the user, only in the presentation layer. This means
no System.out.println's in the lower layers, except temporarily for debugging.
2. Don't ever call System.exit()
from anywhere but main(). Instead, generate an exception to tell the app
what's going on.
3. The business layer service
APIs should be able to handle all the needed actions for the apps in the
presentation layer, i.e., the apps should not call the DAO APIs directly.
4. The DAO should provide all
the DB actions needed by the logic layer, in a way natural to the business
layer requirements. No SQL knowledge should be needed by the business
logic programmer.
5. No service or DAO object
should construct another service or DAO object, and the service and DAO objects
should all be set up and shutdown by special code..
6. Errors in the DAO layer
should throw SQLException (pizza1) or Hibernate RuntimeException (pizza2)
caught in the business logic layer and rethrown as ServiceException.
7. Errors in the business logic
layer should throw ServiceException, caught in the presentation layer.
8. Don't call up to a higher
layer (that pattern is what makes them “layers”).
9. Consistent with the earlier
rules, as much code as possible should be pushed down from the presentation
layer to the logic layer. The presentation layer has the minimal code
needed to interface to the user.
10. Consistent with the earlier
rules, as much code as possible should be pushed down to the DAO layer from the
logic layer. However, the DAO code should make no business decisions. The
facts from the data should presented by the DAO to the BL, and the BL should be
completely in charge of changes to the database.
Entity Objects (also known as domain objects, code in
package domain)
1. An entity object
represents (as a "scratch copy") an entity instance in the database,
and should have a unique id "id" that corresponds to its PK in the
database.
2. However, not all entities in
the database need to be represented by domain objects. The ones that are
needed are the ones the business layer needs to compute with to get its job
done and communicate with the presentation layer.
3. Domain objects may have
related information from the database in addition to what is in the entity
table row. In particular, Sets can hold multivalued attributes or other
one-to-many related data for the entity instance. They can be Sets of other
domain objects or just Sets of Strings, say.
4. Domain objects may be created
in the service or DAO layer (from database data), but modified only in the
service layer. They may be passed to and read in any layer.
For pizza2 (it has
transactions, missing in pizza1):
1. All database statements are inside of some transaction.
2. Transactions are started and committed or rolled
back in the service layer, because it's in charge of the business logic and
transaction boundaries are important to the semantics of application actions.
3. A transaction must
never include user input or output. Thus the service layer needs to finish a
transaction before returning from its top-level call.
4. It is particularly important to mark local helper
methods as private in the service layer. They don't need to start a
transaction because one should already be in progress when they are called.
Questions to
answer:
1. Layers. In memo.txt.
Look at the code in pizza2
and see if you agree that these rules about layers are obeyed by these
implementations. Report on any deviations you see.
a. Discuss how you can be sure that rule 2 for layers is being followed.
Assume you're using a UNIX shell (hint: use grep) or eclipse (use search
capabilities)
b. In particular, discuss how you can be sure that rule 3 for layers is
being followed. Hint: consider what an app would need to have to call a
DAO.
c. Similarly discuss rule 4 for layers.
d. What is the "special code" of rule 5 for layers?
e. In pizza2, we could drop the "day" parameter to
PizzaOrderDAO.findOrdersByRoom and instead call AdminService.getCurrentDate()
inside that method to get today's date, since in fact we only ask for status on
today's orders. What rule would be broken if we did this?
2. Domain objects In memo.txt
a. What tables in pizza2 are not represented as a domain classes? How does their information get passed through
the DAO interface?
b. Point to an example of domain object rule 3's Set idea in pizza2.
c. What types of pizza2 domain objects pass through the service layer API?
d. Do all four types of techconf1 domain objects pass through the DAO
API, or what?
3. Game
Project Model, v1.
Once we have multiuser Pong, we would like to track statistics for Pong by
Player. So we need Players and our one game, but we want to handle other
two-player games in the future too, so assume Pong and TicTacToe. When two
Players play a game, that makes a Match, as shown on pg. 367. Although we don’t
want Leagues and Tournaments as in Arena, we would like pairs of Players to be
able to play a sequence of matches, all Pong or all TTT games. Let’s call this
a Tournament even though it’s not set up by a director but just defined by the
players themselves. We want to be able to report statistics for
Tournament/Player combinations as well as by Match/Player and Game/Player
overall. However, consider computing aggregated statistics rather than holding
aggregated (summed-up) statistics objects. Propose an object model with Game,
Match, Player, Tournament and Statistics. Game, Match, and Statistics are
subclassed by game type as shown on pg. 338, but don’t show the subclasses on
this diagram for simplicity. For now, don’t add other classes. Draw a UML class
diagram for it at the detail level of Figure 9-11. Be sure to show how Game is
referenced from the other classes. Keep Game a pure game implementation class,
that is, don’t give it more responsibilities such as knowing about all the
matches or tournaments. It does know how to create a single Match, as shown on
pg. 338. Hand-drawn or in file
hw6/game_model1.{jpg,pdf}.
4. Game
Project Model, v2.
Note that your diagram for 2. is incomplete in that there is nothing that knows
about all the tournaments or all the players. Propose one or more classes that
handle this need. Draw the class diagram with your proposed class/classes.
Hand-drawn or in file hw6/game_model2.{jpg,pdf}.
5. Game
Matches. In
Match, pg. 338 and 367, we see playMove(p, m), where p is a Player and m is a
Move, pg. 339. What should a PongMove
be? A TicTacToeMove? A single match has a GameBoard object holding the current
state of the game. What should the Pong object for this be? Discuss any
problems or considerations in this part of the design. Answer in memo.txt.
6. Hibernate
Chat.
Continuing on chat functionality for Pong, set up a Java project called
"hibernate_chat" and convert your chat programs Send.java and
Receive.java. They no longer need command-line arguments for database type,
username and password, because this is included in the hibernate configuration.
Use the build.xml and database/build.xml from pizza2 modified so that "ant
load-oradb" and "ant drop-oradb" (and load/drop hsqldb) work to
load and drop the table. In the main build.xml, “ant config-oradb” and “ant
config-hsqldb” should work as in pizza2 to set up the Hibernate configuration,
and "ant sysTest" runs the same system test as we had in chat. Follow
the general guidance of pizza2’s PizzaOrderDAO and DbDAO to set up MessageDAO.
Similarly use StudentService to guide MessageService, and PizzaSystemConfig to
guide ChatConfig. Deliver eclipse project in hw6/hibernate_chat
Deliverables
We will collect your work electronically from your hw6 subdirectory of the cs680 directory. Drawings can be handed in at class time.
Your memo should be pure ascii text, with no markup (no html, no MS Word). When printed on the Department printers no text should be lost at the ends of lines. If you want to submit some hard copy of diagrams, you may bring them to class the day the assignment is due.
We will look in your cs680/hw6 directory. It should contain, by Thurs midnight, Nov. 13:
By
Sunday midnight, Nov. 18: