Reshaping IT Project Delivery Through Extreme Prototyping
Pages: 1, 2, 3, 4

The Idea of a PageData or Page Object

If you examine closely the dynamic prototype that is being suggested here you will see that it is advantageous to represent an HTML page as a Page object in memory. This Page object parallels the physical HTML page: it will have data on it, it will have actions on it, etc. Consider the following code:

public class MyWebPage
{
   //Concentrate your data in one place
   MyWebPageData;
   
   //ui controls
   uiControl1;
   ...
   
   //Population etc
   onload(){}
   postback(){}
   
   //Actions on the page
   action1(){}
   ...
}

public class MyWebPageData
{
   //data only
   field1;
   list1;
   object1;
   ...
}

All the data on a web page is encapsulated into a page object. This approach has the following benefits:

1. Provides a conceptual model for developing the UI, irrespective of how the data is organized in domain objects.
2. The page data object can be streamed in a variety of formats including XML in response to incoming URLs.
3. Allows UI developers to complete their contract without heavily depending on the backend systems.

Architecture for a Dynamic Prototype

Consider the following architecture in Figure 2, where an action on a web page is directly accessing the DAO objects and manipulating them for a certain business purpose.

Figure 2. Actions directly using DAOs

In this scenario, the Action class is responsible for two things. On one side, it interacts with the UI of which it is part of. On the other side, it interacts with business logic. There is a distinct advantage in separating these two concerns. If the action class can postpone the business concern through a stub or a service, then the UI can be built independently of the business service. This will allow division of labor and hence quick deliverables by throwing more people at it.

With this thought in mind, let me re-architect Figure 2 into Figure 3:

Figure 3. Actions using services

The key features of this design are:

1. Service methods are encapsulated into one or many service interfaces.
2. Each interface will be implemented by an implementation.
3. Implementation will deal with business logic and also the persistence of the business objects.

This can be further enhanced by introducing a static wrapper for the services, as in Figure 4:

Figure 4. Actions using services via a static wrapper

1. IServiceInterface will define services. There may be a couple of these interfaces in the whole project.
2. Inputs and outputs to these methods are plain domain objects.
3. An implementation of this interface will call DAOs.
4. A static wrapper will front the implementation by hiding any construction details of one or more implementations.
5. Static wrapper can intercept services for value added services such as:
   1. Transactions
   2. Logging
   3. Simulation

The key concept in dynamic prototyping is to build the system (as much as possible) as if there is a services layer implementation from the start fulfilling the contract. Initially, the implementation is going to be using some mechanism to simulate the contract. The static wrapper or an equivalent scheme can nicely package the interfaces into some sort of a distributor, where multiple implementations can co-exist. The article Server-Side Typed Event Distributors further explores these ideas and points to an architecture where each method of an interface can be gradually refined for a final implementation. Under this architecture, the static wrapper will look more like Figure 5:

Figure 5. Design of static distributor of services

The finer points of this architecture are:

1. Static wrapper can hold multiple implementations.
2. The default service implementation will provide a filler for each method.
3. Each implementation can pick and choose which method to implement.
4. Static wrapper will use a certain hierarchy to pick an implementation, usually starting with the real implementation.
5. This means, when the real implementation has a valid method, it will be called and not the other simulated or secondary ones.

Pages: 1, 2, 3, 4

Next Page