Introduction to Application Frameworks

AS THE AUTHOR of this book I have a single goal, which is to sell you on the idea of application frameworks. Throughout this book, I will talk about many aspects of application frameworks. I will explain, for example, why a framework is important in application development, and what techniques can be used in developing an application framework. I believe in explaining through concrete examples, so I will show you how to develop an application framework through a sample framework that I have developed, called SAF, which is short for Simplified Application Framework.

The SAF sample framework is written in C#, a computer programming language that provides object-oriented features for the development of an application framework. Some good hands-on experience with the Microsoft .NET Framework, C#, and object-oriented programming would undoubtedly be of great benefit in understanding the technical aspects of this topic. Many characteristics of .NET technologies to which we will refer in discussing application frameworks are advanced topics that you may have read about but have not yet used yourself, and you can take this opportunity to see how many of those .NET features are actually implemented and used in the sample framework. The “gang of four” (GOF) design patterns discussed in this book are another area in which you can learn a great deal about good application design. Application frameworks often rely on those patterns for the reuse of their designs. You will learn more about many of the GOF design patterns as I show you how they are implemented in the framework throughout the book. If you buy into the idea of application frameworks, and at the same time learn about many .NET technologies and design patterns that you can use in your projects after reading this book, you will make me a happy author. 

Before I start selling you on the idea of application frameworks, we first need to define what it is. Let us start with the definition of framework from the American Heritage Dictionary: “A structure for supporting or enclosing something else, especially a skeletal support used as the basis for something being constructed; a fundamental structure, as for a written work or a system of ideas.”

The term “framework” can mean different things to different people. Politicians use the word to describe certain policies and certain approaches to problems. Architects (the ones who design buildings) use the word to describe the skeleton or frame of a building. Software architects use the word to describe a set of reusable designs and code that can assist in the development of software applications. It is this meaning of “framework” that we will discuss in the rest of the book.

The word “structure” is really at the heart of any framework. Structure exists everywhere. When you see that a new construction is underway, the first thing you observe is that its structure is built first. When I am writing a book, I first come up with a structure, or outline, for what I will be discussing in the book. By developing a “structure,” we are forced to look at the big picture. In the case of a building, a focus on the big picture forces the architect to focus on how one portion of the construction affects every other aspect. In the case of writing this book, such a focus forced me to think about how chapters and topics are organized to make the whole book easy for readers to understand.

Structure also plays an important role in application development. A fairly complex application can contain so many moving and changing parts that no human being can keep track of their interrelationships. Structure helps us organize those moving parts into a few major ones that you can easily track. As we start developing the application, we can rely on structures to provide us with a context for detailed implementations. An application framework provides developers with a structure and template that they can use as a baseline to build their applications. Such a framework often consists of abstract classes, concrete classes, and predefined interaction among the classes throughout the framework. Developers can then build the application on top of the framework and reduce the development effort through reuse of code and designs provided in the framework. Figure 1-1 provides a high-level overview on how an application framework relates to a business application.

Of course, many applications have been developed without using a framework, so you can probably do the job without even knowing the concept of a framework. In the world of application development, everything can be done, with or without a framework. However, by taking an application framework approach, you can take advantage of the many benefits that a framework can offer your application. It is these benefits that lie at the heart of the promotion of application frameworks.

Figure 1-1.  High-level overview of the relationship between an application and the application framework

A History of Application Frameworks

The concept of the application framework is not new, and various types of frameworks have been around for a couple of decades. The first widely used framework was the Model-View Controller (MVC), a Smalltalk user interface framework developed by Xerox. The approach of MVC, which depends on the Observer design pattern, has been adapted in many user interface systems. In addition to the Smalltalk MVC, other user-interface frameworks have emerged to assist in the development of applications running under several operating systems. Some of the well-known user-interface frameworks are MacApp and MFC, which assist in application development on Macintosh and Windows systems, respectively.

Although the concept of a framework has been widely adopted in user-interface development, it is not limited to the user-interface framework. The framework concept is also used in generic application development. Taligent, a company that develops object-oriented operating systems, alerted the software industry to the possibilities of the framework concept. Taligent was formed in 1992 as a result of collaboration between IBM and Apple to create new operating systems that would run on any hardware platform. However, as time went by, the industry became less interested in such new operating systems. Taligent shifted its focus to developing framework layers that sit on top of existing operating systems. CommonPoint, a framework developed by Taligent, aims to reduce application development effort by providing developers with a comprehensive programming environment, similar to what Sun’s Java environment offers today through its Java language and runtime virtual machine.

Sun’s Java environment and Microsoft’s .NET environment provide their own frameworks along with the new languages and virtual machines. Those who work with Java or .NET can fully appreciate the benefits what those two frameworks have offered to application development in the past several years. Java and .NET are both frameworks that target all types of applications, and thus such frameworks must not contain any business-domain–related classes and designs. However, there exist frameworks that sit on top of such generic frameworks and provide services and expertise for certain specific business domains, such as supply chain systems and financial applications.

IBM (which later bought Taligent) also developed its own business-domain–orientated framework, called the San Francisco Project. San Francisco was developed using Java, and it consists of the application frameworks for various business domains, such as order management, warehouse management, and general ledger management. Unlike general-purpose frameworks such as Java and .NET, the San Francisco framework is designed especially for specific business domains. 

There are five major benefits of using application frameworks: Modularity, Reusability, Extensibility, Simplicity, and Maintainability.

Modularity, the division of an application into structural components, or modules, allows developers to use the application framework in a piece-by-piece fashion. Developers who want to use one component of the application framework are shielded from potential changes to other parts of the framework. As they build applications on top of the framework, their development is better insulated from changes occurring in other parts of the application framework, resulting in a significant boost to their productivity and a reduction in the amount of time spent on fixing code affected by other parts of the application. By dividing the framework into modules, we can maximize productivity by assigning a developer the specific part of the application that would benefit most from that developer’s expertise. The advantage that accrues from modularity can be seen, for example, in Web applications: developers who are expert in presentation user interfaces can be more productive when assigned to the front-end portion of the application, while developers who are expert in the development of application business logic can be more productive when assigned to the middle tier and back-end portion of the application. Similarly, developers can leverage the framework module related to the user interface during their development of the presentation tier of the application, while other developers can leverage the framework module related to the development of business objects during their development of the middle and back-end tiers of the application.

Reusability of code is one of the most important and desirable goals of application development. An application framework provides such reusability to the application built on top of it not only by sharing its classes and code, but by sharing its designs as well. Applications usually contain many tasks that are similar in nature. However, different developers on the team often create their own implementations of these similar tasks. The result of such duplicated implementation is not only the unnecessary waste of resources on the duplicated code, but also the problem of maintainability further down the road, since any change to the task must be duplicated in multiple places throughout the application to ensure its integrity. On top of that, each developer might use a different design approach during implementation. This opens the application to risks of poor software design, which could lead to unforeseen issues down the road. With an application framework, however, we can move much of the duplicated code and commonly used solutions from the application layer to the framework components. This reduces the amount of duplicate code developers have to write and maintain, and significantly boosts their productivity. The application framework is also the place where we can bake many well-tested software designs into the components. Developers may not always be experts in software design, yet as they start using these framework components to build their applications, they unavoidably reuse many good software design approaches, such as design patterns that underlie the framework components.

Extensibility, the ability to add custom functionalities to the existing framework, allows developers not only to use the framework component “out of the box,” but also to alter the components to suit a specific business scenario. Extensibility is an important feature for the framework. Each business application is unique in its business requirements, architecture, and implementation. It is impossible for a framework to accommodate such variation by itself, but if a framework is designed in such way that it leaves room for some customization, then different business applications can still use the generic features of the framework, yet at the same time developers will have the freedom to tailor their applications to the unique business requirements by plugging the customized logic into the framework. With a high degree of extensibility, the framework itself can become more applicable to different types of business applications. However, in creating a framework, its extensibility should always be determined in the context and assumptions of the application you are trying to develop. Each time you increase the extensibility of the framework, your developers may need to write more code and require more detailed knowledge about how the framework operates, which will have a negative impact on their productivity. An extreme scenario of a highly extensible framework is Microsoft’s .NET framework itself, which is designed for development of a wide variety of applications. Indeed, there are few constraints in developing applications using the .NET framework, but as a result, you lose the benefits of what an application framework can provide. The key is to add the flexibility and extensibility to the places in the framework that are more likely to change in the particular type of application you are developing.

The term “simplicity” here means more than just being simple. Simplicity refers to the way the framework simplifies development by encapsulating much of the control of process flow and hiding it from the developers. Such encapsulation also represents one of the distinctions between a framework and a class library. A class library consists of a number of ready-to-use components that developers can use to build an application. However, developers must understand the relationships between various components and write process flow code to wire many components together in the application. On the other hand, a framework encapsulates the control of such process flow by prewiring many of its components so that developers do not have to write code to control how the various components interact with each other. Figure 1-2 illustrates the difference between a class library and a framework.

As you can see from the figure, in a class library approach, the developer must provide the code to manage the flow of control between different instances of the components in the class library. In order for developers to “wire” the object correctly, they must have a full understanding of each component involved and the business logic needed to make all the components work together. In the framework approach, developers have only very lightweight wiring to code inside the application, since most of the process flow is managed by the framework itself. By hiding such process flow between different components, developers are freed from writing the coordination logic for the components and going through the learning curve required to write such coordination code. By moving the process flow logic from the application to the application framework, the framework designer can use his or her architecture and domain expertise to define how components should work together inside the framework. As a developer starts using the framework, he or she can be highly productive in developing the application knowing very little about how the framework components work together.

Figure 1-2.  Comparison between a class library and an application framework

Maintainability, the ability to effectively support changes to the application as a result of changes to the business requirements, is a welcome side effect of code reuse. Framework components are commonly shared by multiple applications and multiple areas within a single application. Having a single copy of the framework code base makes the application easy to maintain, because you need to make a change only once when a requirement changes. The application framework may also contain many layers. Each layer makes certain assumptions about the business the application is intended to serve. The bottom layer consists of framework components that make no assumptions about the business. They are also the most generic components in the framework. As you move higher up the stack of the layers, its components depend on more business assumptions than do the previous layers, and hence are more susceptible to change when business requirements and rules change. When changes do occur, only the components at the layer where the business assumption is broken need to be fixed and tested. Therefore, by injecting different levels of business knowledge into different levels of the framework layers, you can reduce the cascade effect of changing business rules and requirements to the application. This also leads to the reduction of maintenance costs, since you need to touch only the code that is affected by the business rule change. You will learn more about the framework layers in Chapter 2.

While application frameworks offer benefits as described above, they also follow the No-Free-Lunch rule. Application frameworks also carry a set of additional costs to the development process. 

You have just seen what wonderful things frameworks can do for our applications; however, while application frameworks are the best choice in many circumstances, that doesn’t mean they are always the right choice. In exploring the possibilities offered by application frameworks, we must not lose sight of what we are trying to accomplish with the application we are developing. There are two areas in developing and using application frameworks that you need to consider in determining whether an application framework will help achieve your objectives: framework development and user training.

Developing an application framework is not an easy and inexpensive effort. In order to develop a highly usable and extensible framework, you need first to find individuals who are not only expert in the business domain, but also expert in software design and development. It is important that those who are developing the framework be competent in both business knowledge and software development. Without business expertise, you cannot create the business-domain–specific framework layers that developers rely on to offset their lack of knowledge of the business domain. Without the technical expertise in software development, you cannot transfer the concept of the framework from theory to the concrete framework code that developers can reuse and extend. Finding people who have expertise in both the business domain and software development is the first hurdle to leap over in the development of a high-quality framework.

Clearly, the design and implementation of the framework demands a significant amount of human resources. Developing the application framework requires different skills from those used in developing an application. The framework designer must determine how developers can benefit from the services and architecture provided in the framework, how to abstract certain common logic in the application so that developers can reuse such logic throughout the framework, and how to provide the hot spots, or flexibility points, at the right place in the framework so that developers can plug in their code to achieve specific results.

Some of the work involved in creating a framework is abstract and relies heavily on assumptions about how developers will use the framework to build the application. It is difficult to get everything right on the first try, since the design can only guess at how the final application will look and how it will be built to solve the business problem. Certain framework components that were originally thought of as shared by multiple parts of the application may turn out not to be, and they should be taken out of the framework. Certain bits of application code that were originally supposed to be unique in different scenarios may turn out to share certain common abstractions, and they should be added to the framework to be shared throughout the application. After the framework has been deployed, new business requirements or changed requirements may result in the addition of new components to the framework and a modification of the existing framework components. As you may imagine, it takes a series of iterations to get the framework right for the applications that are built on top of it. The development cycle for a framework is similar to that of a regular application, namely, Analysis, Design, Development, and Stabilization in a reiterative fashion. Framework development is very much an evolving task, and it demands continual development and support efforts to ensure its relevance.

Because the users of the framework are the developers who are building the application, user training for the framework means training the developers to use the application framework. In order to take advantage of what the framework offers, developers must have sufficient knowledge about the application framework and how to use it in their development. However, learning about a framework can be a time-consuming process. There are several factors that contribute to the difficulties in learning an application framework.

By its nature, the application framework is an incomplete application. Many missing parts of the framework will need to be filled in with application code written by the developers. However, before the application is complete, the framework itself may look obscure to many developers, since not every piece in the framework is well connected from beginning to end.

Application frameworks also contain much wiring needed to control the process flow throughout the framework. Although one of the goals of the framework is to hide such complex wiring from the developer, during training, developers may have a harder time understanding how the framework works as it does, because much of this wiring and the dependencies among classes in the framework are indirect and complex.

As with any new product and programming model, an application framework contains many APIs, services, and configuration settings that are strange to developers, and it will take some time for developers to work with the framework before they become fluent with it and fully productive in developing applications based on it.

Despite this learning curve, we can speed up developers’ adaptation of the framework by creating well-written documentation and samples that show developers how the framework is used in various scenarios. In the case of programming, an example is worth a thousand words and pictures.

With the potential development cost and efforts in mind, we can weigh whether we need an application framework. Not every application needs to be built on an application framework, and many applications have been successfully developed without one. There are situations in which you want a quick solution produced on a limited budget, and thus the savings on the development effort through the framework may not cover the extra development effort invested in creating the framework. In contrast, there are situations in which an application framework is shared by multiple applications and would significantly reduce the overall development effort. There are also situations in which you want to invest in the application framework today so that it can provide an extensible and reusable foundation for future development. What it comes down to is whether an application framework will help you achieve the objective you set for your project. Developing an application framework is like investing in the stock market; good investments are not judged on whether they are making money today, but on whether they support your investment objectives.

In this introduction to application frameworks, you have learned the definition of the application framework and have read a brief history of it. We then looked at how we can leverage a framework in application development to reduce the overall development effort. We discussed the benefits of using an application framework as a starting point for the business application we are developing: modularity, reusability, extensibility, simplicity, and maintainability. We also discussed some of the cost of developing and using a framework, such as additional development effort and developer training issues. Knowing both the benefits and costs of developing an application framework helps us make the right choice whether one should be used in a particular scenario. In the next chapter, we will look at what is inside a framework, and see how to develop an application framework that is both reusable and extensible through the use of object-oriented techniques.