SoftSlate Commerce
Home » Documentation » HTML Documentation

Application Architecture

SoftSlate Commerce uses a strict Model, View, Controller (MVC) architecture to organize its classes and files. The Model is further separated into two sections: classes devoted to interacting with the database (DAOs), and classes devoted to processing business logic. The result is four distinct layers to the application, illustrated by the following flow chart:

The Web Controller or Struts layer provides the mechanisms that control the routing of each web request through the system (the "C" in MVC). In SoftSlate Commerce there are three Struts modules, one for the main, customer interface, one for the administrator interface, and a small one for the installer tool. The customer interface and the administrator interface are further broken down into several units loosely organized by functional area, including "product", "customer", "order", "core", etc.

For the customer and administrator interfaces, the Web Controller or Struts layer consists of the following classes and files:

In short, the role of this layer is to take in each browser request, to validate the browser request, to invoke the classes in the Business layer responsible for processing the request, possibly to handle certain processing itself (such as recording information in the browser session), and finally to route the request to the appropriate Tiles definition in the Presentation layer.

Why separate the Web Controller into its own layer? Along with the Presentation layer, the Web Controller or Struts layer encapsulates all the processes that relate to SoftSlate Commerce being a Web application (as opposed to a GUI or some other application). For example, instances of javax.servlet.http.HttpServletRequest or javax.servlet.http.HttpSession are never referred to or used in the Business or Data Access layers. This separation makes it possible to use the same back-end processing with different front-end systems, such as legacy applications.

[Note]Note

Because of its use of the Struts web application framework, a familiarity with Struts is very useful when developing with SoftSlate Commerce. A great amount of information is available online and in books about Struts. For more, visit the Struts home page at http://struts.apache.org.

The Business layer is responsible for processing the application's business logic and representing the application's state in the form of Java beans. For example, in the case of a request to add an item to the user's cart, the Business layer will initialize the user's cart if it hasn't been already, create new objects representing the items in the cart, and then communicate with the Data Access layer to store a representation of the cart in the database.

The Business layer consists of the following classes:

The com.softslate.commerce.businessobjects package includes two types of classes. Processors (ie. those classes named *Processor) contain business processing logic, whereas Beans (ie. those classes named *Bean) store application state.

Each concrete processor class and bean class has a corresponding Java interface, which the rest of the application uses to instantiate and manipulate it. For example, the processor used to handle various requests related to a user's cart is named com.softslate.commerce.businessobjects.order.BasicCartProcessor . However, throughout the rest of the application, instances of BasicCartProcessor are always referred to through its corresponding interface, com.softslate.commerce.businessobjects.order.CartProcessor . This practice provides a huge benefit in terms of customizing SoftSlate Commerce: through a simple configuration change, you can change the concrete class the application uses to something else. As long as it implements the original interface, the rest of the application can use it just as it did the original class. In your new custom class, however, you now have the ability to override any and every method to implement your own custom functionality. We'll explore the nuts and bolts of doing this in more detail later. The exact same feature is available for all the classes in the Data Access layer as well.

The Data Access layer is responsible for writing and retrieving data to and from the database, and returning the results to the Business layer. For example, in the case of a request to add an item to the user's cart, the Business layer will invoke classes in the Data Access layer, which will do the work of inserting and updating the various tables in the database that store a representation of the user's cart. Starting with version 2.x, SoftSlate Commerce employs the Hibernate persistance framework to handle all of its database interaction.

The Data Access layer consists of the following classes and files:

After the Web Controller layer routes the request to the Business layer and retrieves the results of the processing, it then forwards the request to the Presentation layer, which is responsible for generating the HTML sent to the user's browser. The Presentation layer is composed of the following files:

For example, in the case of a request to view a product detail page, the Web Controller layer will place the requested product information retrieved from the database in the request scope, (in the form of an instance of com.softslate.commerce.businessobjects.product.Product ) . It will then forward the request to the Presentation layer, to output the HTML containing the information to the user's browser.

SoftSlate Commerce employs the Tiles framework, which is distributed as part of Struts, to organize the JSP templates responsible for presentation. When the Web Controller layer executes a forward to the Presentation layer, it specifies one of the Tiles definitions defined in the tiles-defs*.xml files under the WEB-INF/conf subdirectories. The role of each Tiles definition is to describe which JSP templates should be used to output the response.

[Note]Note

There is much more information about Tiles available in books and online. Refer to the Struts Web site for more details.

In the case of a request to view a product detail page, the Web Controller layer forwards to the product.product Tiles definition, which is defined in the WEB-INF/conf/product/tiles-defs-product.xml file. That file tells Tiles to use the WEB-INF/layouts/default/product/product.jsp JSP template to display the body of the product page.

[Note]Note

SoftSlate Commerce extends the Tiles framework to first look inside the custom directory each time a given template is called for, before using the template found in the default directory. This is how a definition that calls for /WEB-INF/layouts/default/core/welcome.jsp will include /WEB-INF/layouts/custom/core/welcome.jsp instead, if it exists.

Copyright © 2009 SoftSlate, LLC. All Rights Reserved.

Powered by SoftSlate Commerce

Foraker Design