Tuesday, September 23, 2008

Just Plain

I've been working on a small application framework together with a friend. The framework is for developing business applications. I will probably post some stuff about this in the near future. We made it with the following requirements.

  • Simple - This is the main purpose of making a framework anyway
  • Transparent - We want you, the user of the framework to be in charge and control of what is going on.
  • Reduce redundancy - We are strong believers of DRY (Don't repeat yourself)
  • Introduce as few dependencies as possible - use what you like, ignore the rest.
The reason for wanting these properties in our framework is as follows. The simple part is easy. We want the interface to be intuitive to use. To accomplish this we choose the simple path over the complex. If something is complex, why not make it without the frameowrk.

In order for you to control what is going on we want to make the framework as transparent as possible. We want the users to be able to do all the same things without the framework, but provide a shortcut by offering a default architecture.

Reduce redundancy means that we want to provide the users of a way to write their code once. As an example this means moving definition of queries from the data layer to the business layer. This way there is one place to make changes, and you don't have to reflect your changes through several layers of code. The data layer is all of a sudden less important, and so is the UI layer. This means that we can supply you with a generic data layer or a ui layer (no layout), and all you have to focus on is your business layer.

By having very few dependencies we remove the reason not to use parts of the framework. Even if you are using large API’s with very strong dependencies and requirements, you can easily use parts of the framework where ever it makes sense and your other dependencies allow it.

The Framework is of course just named Plain