Harvested Frameworks
Saturday last week I attended a conference on “Agile Development for Fun and Profit” conducted by ThoughtWorks. Martin Fowler, the chief scientist of ThoughtWorks, gave a talk for an hour on role of technology in Agile and the growing movement to change in technologies and towards lightweight frameworks. He fantastically walked the audience through the need from the SmallTalk days on changing the behavior of the program at run time.
He talked about lighweightt frameworks like Spring and Hibernate which has picked up lot of momentum over the last few years. But the trend seems to be more towards “Harvested Frameworks” like Ruby on Rails (ROR). Harvested Frameworks are essentially frameworks initially framed to solve a particular problem domain. Then you abstract and extract the essential elements that do not contain any code associated with the actual project and then generalize it. ROR framework follows convention over configuration technique. It assumes that you are going to follow certain style and structure in your project and the framework takes care of most of the configuration. This is quite contradictory to lot of J2EE related frameworks where you have to map elements, typically in an XML configuration file. There is more chance an harvested framework would become mainstream rather than frameworks which are built independent of projects from scratch.
A good example to explain convention over configuration in ROR is its in built Object-Relational Mapping (ORM) capabilities. For example if you have a table named Employee in your database it makes lot of sense to have an object Employee that is used for persistence. So you don’t need to do anything, the framework knows that you have a model named Employee and it should map it to the table Employee in the database.
And one more fantastic point that Martin brought was that harvested frameworks are opinionated which means it is built of certain standards and structure which you are accepting to adhere to, it does not try to address all areas/concerns. For example if you want to create a ROR application and you want to integrate with a legacy database such as Mainframe, then ROR is not for you.









