Versions Compared

Old Version 12

changes.mady.by.user Stephen Turner

Saved on

compared with

New Version 13

changes.mady.by.user Stephen Turner

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Panel

Overview

The Education Systems framework for developing Java-based web applications can seem bewildering to a new developer. Indeed, some of us who have worked with the framework for a while still find ourselves scratching our heads from time to time. So I hope this document will serve as a place for newbies to come and learn about how we put web apps together, and also for old hands to remind themselves about some of the dusty, forgotten corners of the framework.

First things first - what is the architecture, design pattern, or structure we follow for our web apps? There's no pithy phrase that captures it all, but here are the essentials:

- Code is written in Java (6)
- JSPs are used for the front-end views
- Oracle database houses the data
- Spring MVC for the web layer
- Spring framework provides the app "container"
- Hibernate talks to the database

We use a fairly standard layered structure for the Java code in the web apps. Conceptually this structure is:
UI Layer -> Service Layer -> Data Access Layer

We also have a Domain component that contains data-holding objects. These domain objects can live in any of the other three layers and are typically passed up or down between the layers.

This diagram illustrates these layers:

Gliffy Diagram
sizeM
nameWeb App Java Layers
version2

...

Panel

Data Access Layer

This is where the Data Access Objects (DAOs) live. A DAO's purpose is to provide a relatively fine-grained set of basic data operations (e.g. get data from the database, update data, etc.).

There should be no business logic or business rules in a DAO - just pure data access. Thinking about alternate DAO implementations may be helpful here. For example, if a DAO contains code like "If the student is a freshman, set some flag to "F" otherwiseload this data, otherwise load that data", it's on the wrong track. This is business-related logic and belongs in the service layer.

Once again, DAOs are singleton Spring beans, so thread-safety is important.

DAOs are coded as interface & class pairs. You will find the DAO interfaces in a "dao" package, and their Hibernate implementations in a sub-package "dao/hibernate". Naming conventions are (for example) RegistrationDAO for the interface and HibernateRegistrationDAO for the class. Again, the use of the interface helps with unit testing, allowing us to test service classes by using mock DAOs that do not need to connect to the database.

One very important consideration for DAOs. You will see many DAOs in the framework that extend Spring's HibernateDaoSupport class and use Spring's related HibernateTemplate. DO NOT USE THIS METHOD FOR WRITING NEW DAOs! This style has been deprecated by Spring for at least 5 years in favor of DAOs as plain POJOs, and use of the Hibernate Session API. Now, with Spring 3.1 beginning to support Hibernate 4, these helper classes have been dropped from the Spring framework. When we upgrade our framework to Hibernate 4, we will need to rewrite code that uses these helper classes. So from now on we should stay away from these deprecated classes. In a nutshell, DAOs should be POJOs and should contain a private instance variable of type SessionFactory. The session factory should be injected by Spring, and DAOs should use the getCurrentSession() method on the factory object to obtain the Hibernate Session, and perform data access using the Session API.

Transactions
Panel