Feb 25
Our framework of choice is Fusebox4.1 because the majority of our developers have procedural backgrounds (including me) so we understand this best.
My feeling is however that the framework should only be used if it fulfils some particular development requirements:
- It makes development faster
- It makes code easier to read and follow and therefore to maintain
- It does not significantly impede the goals of the system (e.g. performance)
If any of these can not be ticked, then you should think again about your use of the framework. In other words use of frameworks should not be a matter of blind dogma, but be seen as just another useful tool; picked up when useful but left on the shelf when inappropriate.
One possible exception to this approach is the 'tiny one-off project'. You know the ones - 'we just want a simple one-off report we can browse to easily' or 'I just need one form to set the status on certain records everything else I can do on the legacy system....'.
I've been caught by these in the past, so a few months ago when I was asked to provide a facility to select and then download in csv file I decided to implement a full fusebox4.1 structured application to house this single download function.
I was certainly tempted to deliver just the requested function with one or two cfm pages, and I could have done this in a few hours.
This approach has paid off, since this system is slowly growing week by week with new features as this client realises how much better a web based solution is to the legacy system they have used to date.
These new features can now be coded in hours and slotted in to the framework with ease.
So while a well structured FB app was justified in the above example a stricter MVC approach, building a full set of data access objects was not justified.
Feb 27, 2006 at 12:24 PM In general I agree but often there will be a trade off between speed of development and ease of maintenance where it will take a bit more development for that extra ease of maintenance in the future. As the majority of time spent on a system is usually during maintenance - I think this is a worthy trade off and perhaps speed of development should be of less important when compared to maintenance.
Feb 27, 2006 at 1:40 PM Yes there are certainly trade-offs to make. However it seems to me that while a framework may require some additional setup time during development, it should then make development faster because the framework handles many common tasks and dictates how each function will be approached to a certain degree. If it does not do that for your team (once they are familiar with the framework) then I would question its use. On the whole however I agree that the ease of maintenance is going to have a bigger imapact overall on time and cost.