Dissection of an Application Framework - Framework Development Techniques
(Page 3 of 7 )
In order to develop an effective application framework, you need to know some common techniques for framework development. The following list shows some useful techniques and approaches that can help you develop a framework that is both easy to use and extensible.
- Common spots
- Hot spots
- Black-box framework
- White-box framework
- Gray-box framework
- Design patterns
Common spots, hot spots, and design patterns are some of the techniques used in framework development. Black, white, and gray boxes represent the approaches you can take to developing the framework.
Common Spots Common spots, as the name suggests, represent the places in the business application where a common theme is repeated over and over again. If certain parts of the application repeat without much variation throughout the application, we can extract such common spots out of the application and package them into components in the framework layer. By moving such common spots into the framework, you avoid the duplication of such common spots throughout the application, and hence promote code reuse. This reduces the development effort when developers can simply referencing to the common spot in the framework from their applications. Figure 2-3 shows how the common spots relate to the framework and business application.
Figure 2-3. Common spots
In Figure 2-3, the application framework contains the components that provide the implementation for various common spots found in the application. When developers start building applications, they will reference the common spots implemented in the framework component instead of developing them themselves. As a result, the amount of application code they have to write is reduced.
To qualify as a common spot, a theme does not have appear in exactly the same way throughout the application. As long as the variations are small, you can still treat them as common spots and handle the small variations through parameterization and/or configuration settings.
The actual task of moving the common spot theme into a framework component is not hard. The difficult task is to identify in the analysis phase the common spots throughout the business application that have not yet been developed. It is not always easy to see through the common theme embedded in the application, and it usually takes a few tries to get it right.
Common spots can exist in both the domain-specific framework layer and the cross-domain framework layer. For example, the exchange of business documents is the central theme of B2B applications. A business document object would be considered one of the common themes that can be turned into a framework component for the domain-specific framework layer. Another example is a data cryptography service. Regardless of the type of application, data encryption and decryption are often applied at different parts of the application. A data encencryption/ decryption component, which simplifies and reduces the amount of code developers have to write to support cryptographic needs in the application, would be considered one of the components in the cross-domain framework layer.
From a technical point of view, implementation of common spots is straightforward. After identifying a common spot, the framework designer can develop the components that encapsulate the theme and logic in the common spot. Such components often take the form of concrete classes or executables. To accommodate the small variations in the component, some configuration data may also accompany the component. For example, you can allocate certain sections in the configuration file for parameterization of the framework components. In terms of adapting such framework components, developers need to write little or no code to use the component within the application.
Common spots capture the themes that are repeated throughout the application; however, each business application is unique, and there are as many spots where each application varies significantly due to the nature of the application as there are common spots. As a framework designer, you need to take account of those variations when designing the framework and make sure that developers can take advantage of the framework not only when there are common themes among applications, but also significant variation and customization between applications. This leads us to the next topic: hot spots.
Hot Spots A hot spot is point of flexibility in the application framework. Another way to look at the hot spot is that it is a placeholder embedded in the framework where application-specific customization occurs.
Hot spots are the opposite of common spots. In a common spot, the framework implements the common themes inside the framework component; however, in the case of hot spots, there is nothing for the framework to implement except to leave an empty placeholder, which is later filled with a custom implementation by the business application built on top of the framework. Because each business application is responsible for providing its own implementation for the hot spot in the framework, the framework will behave differently for each business application. This is how a framework can be designed to suit different business applications in spite of significant variations among these business applications. Figure 2-4 illustrates how an application framework achieves flexibility through hot spots.
Figure 2-4. Hot spots
In Figure 2-4, components in the application framework layer consist of different hot spots, or empty placeholders for customization. Each application may use a number of framework components throughout the application. When the application uses a framework component that contains the hot spot, it needs to provide the implementation only in the hot spot in order to use the framework. The different designs and shading of the hot spot shapes shown in the figure represent the different implementations among various applications. As you can see, by implementing different logic inside the hot spots, each application will elicit different behaviors from the framework components.
As with common spots, identifying the hot spots may not be easy. To identify a potential hot spot, you must understand the business domain inside out and understand which points in the business application will potentially need to be customized. Having too many unnecessary hot spots in the framework will lead to extra coding effort for the developer team. Having too few hot spots makes it harder for the developer team to adapt the framework when desired customization becomes difficult due to the inflexibility of the underlying framework. Although it is possible to achieve such customization by overriding most or all the virtual methods in the base class, doing so would diminish code reuse and the purpose of inheritance.
Creating hot spots in the framework is not as straightforward as creating common spots. There are two approaches on how hot spots are enabled in the framework: the inheritance approach, and the composition approach. Let’s look at the inheritance approach first.
The Inheritance Approach
The inheritance approach is driven by two important object-oriented concepts: hook methods and template methods.
 This chapter is from Developing Application Frameworks in .NET by Xin Chen (Apress, 2004, ISBN: 1590592883). Check it out at your favorite bookstore today. Buy this book now.
|
Next: Hook Methods >>
More .NET Articles
More By Apress Publishing
