Jonathan Crossland
Posts: 630
Nickname: jonathanc
Registered: Feb, 2004
|
Jonathan Crossland is a software architect for Lucid Ocean Ltd
|
|
|
|
Understanding Framework Types
|
Posted: Mar 17, 2009 9:38 AM
|
|
Traditionally, you read about the following two types.
Vertical Frameworks
or an Application Framework that covers all the elements top to bottom. It may be narrow, or relatively wide. However, it is most likely to be specific to a type of Application and not concerned with cross application reuse. For example: Employee Benefits, Batch Manufacture, Ledger and things of that nature. It would contain its own logging, errorhandling, data access, auditing. It would allow extensibility, configuration, but from a vertical perspective.
Horizontal Frameworks
or Infrastructure Framework is concerned with the wider services, and does not dictate the higher layers of an Application. So it would contain a wider range of services, but offer less vertical specializations.
A Vertical Framework is an Application
Ultimately, both types would be striving for the shape of the other. A tall narrow vertical framework, would be striving for more 'width', and likewise a Horizontal Framework would be striving for 'height'.
Both these kinds of Frameworks can be implemented with the same tools and concepts, but with a different focus.
If you focus on delivering an Application, you are concentrating on application requirements, usability, and not a framework's requirements. Therefore, I believe that a Vertical Framework is just an Application that has a 'built-in' framework, which is being worked on while developing the application.
That does not exclude it from the term framework, instead, I believe that all Applications should be built in this way.
Everyday Framework Development
So what does it take? I don't recommend that without experience you go ahead and develop Frameworks within your current project, but do learn about it and try small Framework like things in your applications.
If we understood, exactly what a Framework looked like, we could tell exactly what to build in our applications that would make it more Framework like and thus more reusable.
In my previous post, I requested 140 characters of a framework definition, which although only a few replied, it is still somewhat revealing.
It is interesting because, most have the correct concept, but when you analyse descriptions, not all terminology is used with the same definition. For example. API is now used almost synonymous with anything you call that has a method, but a Framework is not an API (Application Programming Interface). A Framework is not an Application, nor is it just an Interface. A Framework is more than stateless calls. A Web Service is kind of like an API. Most of the time these are stateless. At least its best practice to have it stateless. Contrary, a Framework should contain state, and is much more than an interface. An API is often referred to as a Library, which is a collection of API. On the state-full side, you are looking at an Object Model, but just a Model is not necessarily pluggable or extensible.
So Object Model, API, Library and software assets of that sort are only 'one portion' of a Framework, and you can use them without it ever being part of one.
So if you are building an Application that contains an API, or library, then you have a useful reusable set of methods or objects. You do not have a framework.
Is it a part solution to a problem? Indeed a Framework can have solutions, and in fact the more the better. But you can create code that solves problems within an Application, not just a Framework. So it cannot be the only answer.
Is it an Independent System of cohesive software. This is true, because the Framework must remain independent from the Application, to maximize reuse. But so too, is a component. Uncle Bob mentions one extra thing in his description, which is absolutely vital, and that is "performs a general function that controls user specified functions". This is vital, as did Paul Tiseo eluded to it also when he mentioned application-specific code. The correlation there is generalization and specialization controlled by the Framework. The Generalized provided by it, and the Specialization executed by it. This polymorphic activity is a vital aspect of a Frameworks definition.
However, both definitions and my first definition also, do not mention MetaData. MetaData is also vital, as it is the very thing that declares the changes, specializations and completes the picture.
So in fact, we can easily conclude that if we build an Application and keep a "subset of cohesive software, library + application-specific code, with generalization and specialization, configurable, extended by means of Framework code using MetaData", we are in fact building an Application Framework within the Application itself. It must be able to be separated out though, to finalize the categorization requirement.
If you are still interested, have a read on "The Quest to Define a Framework"
Read: Understanding Framework Types
|
|
Previous Topic
