Model

Supported Technologies 

The IS&T-licensed SourceLabs SASH Stack (Spring, Axis, Struts, Hibernate) comprises the standard technologies for use in insideMIT Java applications.  In addition to SASH Stack compliant versions of Spring and Hibernate, Open Enterprise Foundation's SAP Java Connector (as used within the sap2java API) is used within the Model. 

Specifications

• For SAP applications, proxy classes populated by SAP R/3 functions must be generated with the sap2java tool and not modified by hand.
• For database applications, dao classes are responsible for retrieving model objects from the database using hibernate.
• model classes are not specific to any front end or back end, but model the business itself. I.e., they do not represent the data for a page, nor do they contain proxy objects or make reference to the back end in any way.
• service classes are responsible for converting proxy objects to model objects, and also for providing any business logic not already provided by the back end.
• There must only be one service per application (not including mock services).
• Collections must be documented to state what objects they contain and what properties those objects contain.
  

View

The View architecture and design standards are maintained by the IS&T insideMIT Design and Development (IDD) team.  IDD's documentation describes implementation rules for such View technologies as Java Server Pages (JSP), JSTL, and Apache Struts Tiles and Tag Libraries.  Please refer to their documentation for specific View standards.  

Controller

 Struts (version-compliant with current SourceLabs-licensed SASH Stack)

• It is the Action class' job to convert model data into a form that can be used by the View (if necessary).
• Every Action that handles user input has a unique Action Form. Other views have request data only. Only data that is shared across multiple pages can be stored in session scope.
• Action Forms should always be in Request scope (never in Session scope unless they are used across multiple pages as in a wizard).
• When an Action's algorithm is dynamic based on user input, Action-chain patterns should be used, not helper-class patterns.
• Actions must only perform one specific function and then either chain to another action or go to a JSP page.
• User input can be validated for correct form, but not for business rules.
• Actions do not return formatted view code (XHTML).
• Collections must be documented to state what objects they contain and what properties those objects contain.

Revision History

(latest on top)