Introducing the Abstract IT Business Application Framework (ABAF)

Last time I've promised to unveil parts of the solution we are building at Abstract IT. Our framework consists of a complete base to build business applications in an abstractly defined way. The framework has been built with a few assumptions/principles in mind:

1. For every part of an application there is only one model.
2. Everything should be done in code as much as possible.
3. Every part of the framework should be extensible and replaceable.

Rationale behind the assumptions:

1. This boils down to the DRY (don't repeat yourself) principle. For example our framework only has one model for the data. This model drives the application but also the database itself meaning no separate manual task to create and change tables, column relations etc.
   
   
2. We try to avoid XML configuration files as much as possible, as they tend to have a life of their own. Somebody once said that every XML configuration file ends up as a programming language of its own, which you have will to learn first to be able to use it. Another reason is us believing that from a mental perspective its easier to stay in the same programming language and environment instead of switching between for example XML and SQL. Designers are also an example of this. They are great in getting things done quickly but they need a different mindset and in the end get in your way when trying to do something difficult. A third important reason is us wanting to have as much compile time checking as possible. This means that the vital parts of the framework, the models, are strong-typed. This helps in preventing mistakes and also aids the developer making the right choices at a given point by utilising intellisense. The last reason is that programming in an object oriented fashion is a good way to capture a model, because the model is still extensible and adaptable. If you put a model in some CASE tool for example, what do you think the odds are you can use the information in a different way? Most of the times you will only get what the tool offers. With models in classes you´ll always have the ability to extend or override behaviour.
   
   
3. We want to avoid vendor lock-in by giving users of the framework the ability to change and extend behaviour as they see fit.

In my next post I´ll talk about the tooling that comes with the framework.