Versions Compared

Old Version 13

changes.mady.by.user Stephen Turner

Saved on

compared with

New Version 14

changes.mady.by.user Stephen Turner

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 4.0
Info

Help is available by sending an email to csf-support@mit.edu
Have any suggestion on how improve this wiki?  Please give us your feedback at csf-support@mit.edu

Panel
Wiki Markup

Quick Links to:

{toc
:minLevel
=3
|maxLevel
=4}
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 Layersversion2
Panel

UI Layer

This layer consists mostly of Spring MVC Controllers, and is identified by the "web" package name in most of our web apps. Controllers are all about web input and output. They handle input from the user's browser (requests for retrieval of data, form submissions, etc), coordinate processing of the input requests, and send back information to the user's browser.

There should be no "business logic" or "business rules" implemented in a controller. Controllers will typically call services to do business logic.

Controllers should not use DAOs (see Data Access Later below) directly.

We use Spring's @Controller annotation to configure controllers as Spring beans. You may see some older controller classes configured as beans via XML, but new code should always use the annotation.

Note that we configure controllers with Spring's default "singleton" scope. This means that there is only one instance of the class in the web application; all users will use the same cached instance of the controller. We must therefore make sure that controllers are coded in a thread-safe way - no state should be kept in instance variables. In fact, instance variables should only be other Spring beans, injected by the Spring container.

...