Fog Creek Software
Discussion Board

Frameworks - Still relevant?

Browsing through various C++ source code compilations one can identify the various frameworks that are built to support the application.  There are base classes and hierarchies and widgets and what not's and who's.

Now move to a VB 6.0 application.  There aren't many frameworks built with VB 6.0.  Maybe a data access library here and there but no real frameworks that build up the application. (I know VB 6.0 is not fullly OO.)

Now move to .NET.  Obviously there isn't much .NET source code out there to view but it would seem to me that building a frameworks for .NET would be A Waste of Time (TM).

So I'm looking for examples of frameworks that people have built using VB 6.0, Delphi, and .NET.  What prompted you to make these frameworks and what do the frameworks support or do for you?

Friday, July 23, 2004

Try this site for a .Net framework:

Ewan's Dad
Friday, July 23, 2004

Java has alot of frameworks...  .NET is slow to game, but it'll get there, eventually.

(Note: I don't necessarily think this is good thing)

Almost Anonymous
Friday, July 23, 2004

no need for frameworks in .NET

I use application blocks. the first google I could find points me to here:

one for data access, one for exception handling, one for UI, one for smart updating, many many more.

integrate as many as you need and just focus on your business logic. These are provided/written by microsoft, represent industry standard best practices, and have been thouroughly tested.


Friday, July 23, 2004

This is a guess, but the explosion of frameworks for Java didn't start until about five years after Java's introduction.  Frameworks are a sign of a mature technology--people have been relying on it for long enough to start building extra layers for efficiency.  .NET will see the same thing in about 3-4 years, when people use it and understand it enough to start pushing it down a level or two.

Justin Johnson
Friday, July 23, 2004

I agree with Justin.  You'll need to develop frameworks where the set of assumptions you can make about *your* typical problem domain is larger than the set of assumptions you can make about all problem domains in general.

Friday, July 23, 2004

There is an argument in the java community that the frameworks grew out of boredom.

Friday, July 23, 2004

If you are as old, crusty, and have been around the block as many times as I have, then certainly you know there is always a new framework looking for a new sucker.

C'mon you kids, move along, nothing to see here ...

Mitch & Murray (from Downtown)
Friday, July 23, 2004

To a large extent, "the" .NET framework is the only one many people will need.  (i.e. the classes written by MS that ship with .NET).

When I worked in Delphi we never really needed any commercial framework, other than the classes that shipped with the product.  Yes, we'd use a few 3-rd party controls here and there, but nothing that you'd call a "framework".

MS's .NET framework is more powerful and extensive than the Delphi one, so I don't really see much call for significant 3rd party frameworks.  Instead, I think 3rd party offerings will be a bit more targeted: specialised user interface controls perhaps, classes to solve common problems (e.g. we're developing a nice set of classes for validation on my current project, but I'm not sure its worthy of the title "framework", at least not in the sense of an all-encompasing structure in which a system is developed).

John Rusk
Saturday, July 24, 2004

there are lots ports of Java frameworks and tools to С#:

NUnit, NAnt, Hybernate, and so on (look at by language C#)

Max Belugin (
Saturday, July 24, 2004

IMO frameworks are need only on/for platforms which aren't smart enough or good enough at offering you the business services you need. A platform emerges seldomly (Java, JSP, PHP, Apache, whatever), business needs change frequently, and the requirements from the software development change accordingly. Whenever the difference between what you get from the platform and what you need from it is too big, I think a framework will appear.

In particular, it seems to me that development languages or environments or platforms which don't provide their own library implementation of MVC yield one or more frameworks sooner than others. If no native MVC implementation exists, more frameworks appear. Toolkits tend to develop into incompatible frameworks.

Monday, July 26, 2004

Frameworks aren't essential to efficient development but they sure do help if you are trying to develop a lot of code in a similar problem space.

My organisation uses a lot of frameworks. Some of them are very simple, some are extremely sophisticated. Once you've bitten the bullet and developed one, the benefits are self evident. There are some gotchas too.

I'll take the case of our Delphi framework which is most topical here. Our framework manages most of the problems that we have to solve more than once but delegates those problems which are more esoteric to be solved by the developer at implementation time. Typically the framework deals with data access, security, look-and-feel, branding, localisation and some aspects of integrating dialogues with the application and with each other. To take the example of our data access methods, we have many sources of data and each one has its own access mechanism within the framework. On the framework side they are very different, but as far as the developer is concerned they are all very consistent in terms of the interfaces that they use. That makes migration from one source to another very easy, so if we want to add another source of data lets say XML, we can do it easily.

A mature framework - ours is at version 2 - makes a lot of the integration of your applications very standard. That means that you can use utilities to generate a lot that code. We can also generate forms against the definition of the interface of the data source. This leaves the developer with the job of perfecting the look of the interface, implementing any clever/performant requirements and other custom (interesting) tasks. The downside is that a lot of the detailed technical work is done by utilities or the framework and that can make the job boring for the average developer.

Testing is another advantage. The functions handled by the framework can be tested at source. That doesn't eliminate the need for testing the applications themselves but if 80% of your source is reused and part of the framework or else generated by utilities, the testing effort is substantially reduced. Either that or you get better quality output for the same test investment. Whichever way you look at it you win.

Another benefit to a frameworked approach is that if you have frameworks for different technologies and system 'layers', you can handle the interfaces between them in the frameworks and then you really do start to see seamless, pluggable integration.

Our mature framework gives us a speed advantage of at least 50% over non-frameworked approaches, dialogue by dialogue. For whole applications the benefits are even more dramatic. If the framework defines the application as a container, then creating a new, fully branded, secure application is as simple as thinking up a name and creating an instance of the application object.

I have been involved with this approach for some years now and I would never do anything else. Once critical disadvantage is that it's a hard sell because your initial investment often produces no benefit. It is also difficult to retrofit, but not hard if you think about it.

Wednesday, July 28, 2004

*  Recent Topics

*  Fog Creek Home