Saturday, 16 August 2014

Websphere Commerce Design Patterns

Websphere  Commerce  Design Patterns are as follows

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.

MVC as everyone knows stands for Model View Controller pattern. It is primarily used to separate the business logic from its presentation.

1.     View - JSP's
2.     Controller –struts framework/BOD framework
3.     Model - All back end objects used for processing like Access beans/EJB’s.

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.

In WCS, view names are used to display the response (JSP) to the client. There may be a need to pass different response based on clients. For eg, a mobile device can render the same page in one fashion, whereas when a request is from a browser the response painted can be different.

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.

<forward className="" name="TestView/<storied>/<deviceid1>" path="/test/TestView1.jsp" />
<forward className="" name="TestView/<storied>/<deviceid2>" path="/test/TestView2.jsp" />

The device id is maintained in  DEVICEFMT table.

So setting the view configurations in struts-config xml as above, the same view can be used for rendering different responses.

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.

Why command design pattern is used in WCS ?

Sometimes it is necessary to issue a request without worrying much about the how the functionality is implemented.  That’s when a command design pattern plays a role. The “command” is a black box to the “client”. All the client does is call “execute ()” on the opaque object.

In WCS, this is used when we call another command from a command. Eg.

TestTaskCmd testTaskCmd = (TestTaskCmd) CommandFactory.createCommand("com.test.commands. TestTaskCmd ",getStoreId());

Here, the command class which calls the task command does not need to know how the task command is actually implemented. All it needs to know is what information needs to be passed and what response the task command will give. 


No comments:

Post a Comment