This post originated from an RSS feed registered with .NET Buzz
by Jonathan Crossland.
Original Post: A Framework should have it's own DSL
Feed Title: Jonathan Crossland Weblog
Feed URL: http://www.jonathancrossland.com/syndication.axd
Feed Description: Design, Frameworks, Patterns and Idioms
When one reads of Frameworks, you cant help from getting the impression that its a large beast of a reusable thing, that then gets reused again and again in the domain the framework 'solves'. You can't be criticized for believing that frameworks are hard to build and harder to grow and maintain. And you would be absolutely correct in thinking that vast amounts of developers cringe at yet another framework to learn. All frameworks are different. They have patterns, but are ultimately different and sometimes extremely hard to learn. All well written frameworks would be beneficial, if it was used.
But look at what we have to work with. We build frameworks using objects. We specify frameworks in classes and modules, with interfaces and contracts. All of this is far too low a level for the future of the Software Framework.
A Framework must be built with a higher level language. A framework must have the ability to see itself as a structure for components and a communications platform for other frameworks. This is hard to do, thus not done yet. I like the Business Component Factory. A great book, written a decade or more ago.
I think that a Framework must have connections:
to other frameworks
to components
In our object-oriented world we have interfaces that are implemented by an object, but usually only one object (or by composition), at the surface implements that interface. A framework needs more than that. A framework needs an interface that can be declared and implemented across objects and traditional boundaries as well.
One possible form of connection specification is XML, or a DSL that defines and builds the Framework's connections.