The Design patterns Present in WCS

Design patterns

The Design patterns Present in WCS:

1. Model-View-Controller design pattern.
2. Display design patterns.
3. 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.