A framework on top of a framework
Juten Tach,
quite interesting discussion at Farata Systems. You have to be logged in to comment, so i write my comment here:
Yakov Fain asks, why should one want to put any kind of third-party-framework on top of the flex framework, when building an application, for example the Cairngorm framework. This is actually a two-part question, and one part has already been answered by Steven Webster in his devnet article at the adobe site. The Flex framework is an “Application framework”, which means it is built to serve as a basis for creating applications, but more in terms of providing basic functionality like data binding, ui components, server communication and so on.
“Architectural frameworks” like Cairngorm or PureMVC on the other hand have a different purpose. They do not really provide practical functionality, they provide a structural pattern, on which you have to build your application, in case you decide to use the framework. Read Steve’s article for a more comprehensive view on this.
So at this point, it should be clear, that it is not redundant or weird to have the Cairngorm framework on top of the flex framework, because they serve for different purposes. The question on how useful is an architectural framework, is a different one.
Having an architectural framework providing a structural pattern, that you have to follow, sounds a bit confusing at first. Why would i ever want to constrain myself in my design decisions? Why can’t i simply choose the best pattern for my use case and “think on my own” about the right structure for my application?
If you are designing your application from scratch, you are thinking of ways to hold your data, how to obtain it, how to pass it to other modules of your application, you are thinking of ways to structure your UI, how the UI knows, what data to display and so on. And once you have figured out, how you want to do things, you start making meetings with your colleagues, because they have to know about all of that, too, of course and your are writing documentation to some extend, depending on how many developers are involved. If you have some experience in this process, means if you have built a couple of applications this way, you will not design anything from scratch anymore, because last time you’ve built your application and you used this little Manager class (or whatever, we all have our little treasure chests, right?), things went out very well, so you think, why not use it again? And the nice side effect is, you don’t have to tell your colleagues over and over again, how to notify some object A of a change in object B, because you just tell them: “We do it like in project x”.
Once you begin reusing some of the design ideas, you have invented in the past, this means actually reusing some kind of design and structural pattern, that you got used to. It is actually your own little “architectural framework”, that you are building there, out of best practices.
Whenever a new application is about to be designed, you can consider, if you have to do things from scratch, because the needs of the project lead you to it, or if you want to go with one of the best practices of your own or if you want to use the best practices of someone else, like using an architectural framework.
Using an existing “architectural framework” to build your application might imply, that you have to make some compromises in favour of reduced design time and reduced time spent in meetings or writing documentation on how your application is basically structured (of course this cannot be reduced to null, since the architectural framework only describes a very abstract structure and does not solve you individual problems for your individual application). Compromise here means, that you are now following the architectural idea of someone else and this will allways be a little different to how you would do things and how it would be best for the project, it is a tradeoff between reduced design time, reduced documentation needs, faster introduction of new developers (if they know the archtectural framework, that is) on one hand and the best-fit individual architecture on the other hand. Since projects usually have limited budgets and time frames, this is important.
In general i think an architectural framework – be it one developed by you or someone else – also serves as a kind of general contract between you and your colleagues on how you want to generally build your application and the positive effect is, that if you use it regularly, people can learn this contract and then, when you actually design a concrete application, you can concentrate on designing the solutions to the concrete problems and finally add: “and besides that, we build our application based on XY”, which means, you don’t have do explain these basic principles again. This also might help later, when it comes to supporting an existing application. If you have developers, that do not know your application, but who do know the architectural framework, that it is based on, it makes life easier for them to dig through the code, as opposed to when you have your completely individual architecture.


Hi Sven
Developers often concentrate all one’s effort on the technical infrastructure, learn different libraries and frameworks believing that the sole use of them makes the software better.
In my opinion a good approach for new projects would be to find an ubiquitous language between domain experts, software architects and developers to make them understand the business domain and following, to make them elaborate a rich domain model which reflects what they are talking about. So the model becomes the basic of the language used by all team members. It becomes the heart of the application as it solves domain specific problems.
This approach does not exclude the use of any frameworks. A framework such as e.g. IoC Container can support the Domain Driven Design philosophy, but the main focus should not lie on it.
This topic has been fascinating me for longer time and I would recommend the book „Domain Driven Design“ by Eric Evans.
Best regards
Hannes