This post originated from an RSS feed registered with .NET Buzz
by Jonathan Crossland.
Original Post: The Every Project Framework - Introduction
Feed Title: Jonathan Crossland Weblog
Feed URL: http://www.jonathancrossland.com/syndication.axd
Feed Description: Design, Frameworks, Patterns and Idioms
Do you think of a Framework as a large 'hole, to be avoided'? Are they too complicated to develop within your project, for everyday development?
I take the view, that a Framework can very easily be part of every project you build, and with great benefit. You just have to understand how.
A Framework has two very important characteristics to give to Applications. A Framework provides structure and infrastructure.
Structure
An application without structure is just text. An Application without structure contains no discernible patterns. If your Application contains no patterns, it becomes complicated. If you have structure and patterns, you have organization, categorization and commonality. An Application must have structure and I know that every single Application ever written has a structure. Every system ever built has patterns. Even the smallest console driven application will have a set way of dealing with arguments, and other code structure.
As developers we are inclined to think in patterns, that is why Design Patterns are familiar and majority of developers can agree that whether they use a Pattern from a book or their very own Design Patterns, a Pattern is a valid helpful tool.
Infrastructure
An Application that does not have infrastructure, is voltage. All Applications sit on levels of abstraction, whether its the assembly language, a runtime, programming libraries and/API, all Applications rely on infrastructure.
The infrastructure of a given Application differs between projects, because as developers we can develop our own levels of abstraction, or rely only on those that are provided, or mostly somewhere in between. Even the smallest application will have some sort of API, or common shared library. We rely on the infrastructure provided at the bottom and the layers of abstraction all the way to our user interface.
Structure and Infrastructure are at the heart of Frameworks. Yes, a Framework can be other things as well, but at its core, a Framework offers structure and infrastructure to an Application.
Within all Applications...
there lies a Framework.
The developers may not have consciously created it, nor was it perhaps designed, but its there. It may be difficult to see, dirty, mixed up within all your code, but it is there!. The trick is to identify it and evolve it as you develop your Application. When you can separate the Application from the Framework (even if the framework is small), means you have separated along the two large dividing lines of change that will occur in your Application. Even if your Framework is not perfect and cannot be used outside of the current project, having it separate aids in the agility and life-time of the Application.
It is a craft, do not expect to build reusable complete Frameworks the first time, but as you build and think in the language of Frameworks, your skills will improve and it will become easier and easier.
"a class is to object, as a Framework is to Application"
Previous Topic
