Design patterns
The
Design patterns Present in WCS:
- Model-View-Controller design pattern.
- Display design patterns.
- Command design patterns.
Model-View-Controller design pattern:
The model-view-controller (MVC) design pattern specifies
that an application consist of a data model, presentation information, and
control information.
The model
(for example, the data information) contains only the pure application data; it
contains no logic describing how to present the data to a user.
The view (for
example, the presentation information) presents the model's data to the user.
The view knows how to access the model's data, but it does not know what this
data means or what the user can do to manipulate it.
Finally, the controller
(for example, the control information) exists between the view and the
model. It listens to events triggered by the view (or another external source)
and executes the appropriate reaction to these events. In most cases, the
reaction is to call a method on the model. Since the view and the model are connected
through a notification mechanism, the result of this action is then
automatically reflected in the view.
Command design
pattern:
WebSphere Commerce Server accepts requests from
browser-based thin-client applications; from applications such as the Sales
Center; and remote applications. For example, a request may come from a remote
procurement system, or from another commerce server.
- Task command: These implement discrete pieces of a business task such as address verification or ensuring passwords comply to the defined password policies. For example, during executing of the Registration controller command a callout may be made to a task command to validate the address entered.
- Controller command: These implement business tasks such as user registration and allocation of inventory. Use these to implement high-level process logic for the business task.
Display design
pattern:
Display pages return a response to a client. Typically,
display pages are implemented as JSP pages. In order to support multiple device
types, a URL access to a page should use a view name, not the name of the
actual JSP file.
The main rationale behind this level of indirection is that
the JSP page represents a view. The ability to select the appropriate view (for
example, based on locale, device type, or other data in the request context) is
highly desirable, especially since a single request often has multiple possible
views. Consider the example of two shoppers requesting the home page of a
store, one shopper using a typical Web browser and the other using a cellular
phone. Clearly, the same home page should not be displayed to each shopper. The
Web controller's responsibility is to accept the request, then based upon
information in the command registration framework, determine the view that each
shopper receives.
