Design patterns uses 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.
Comments