web analytics
Principles for Developing Application Frameworks Options
codeling
Posted: Tuesday, December 15, 2015 12:53:55 PM

Rank:Advanced Member
Groups: Member
Joined: 12/11/2015
Posts: 915
Points: 3843

Simplicity

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 the application developers can use to build an application. However, the application 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 the application developers do not have to write code to control how the various components interact with each other. The following figure illustrates the difference between a class library and a framework.

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 application 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.

Sponsor
Posted: Tuesday, December 15, 2015 12:53:55 PM
codeling
Posted: Tuesday, December 15, 2015 1:40:15 PM

Rank:Advanced Member
Groups: Member
Joined: 12/11/2015
Posts: 915
Points: 3843

Maintainability

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. The application framework may also contain many layers. Each layer makes certain assumptions about the business the application is intended to serve. 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.

Users browsing this topic
Guest

Forum Jump
You cannot post new topics in this forum.
You cannot reply to topics in this forum.
You cannot delete your posts in this forum.
You cannot edit your posts in this forum.
You cannot create polls in this forum.
You cannot vote in polls in this forum.


© 2017 Digcode.com. All rights reserved.