Application Frameworks - Buy, Build, or Assimilate?

I was curious as to what other shops are doing regarding base application frameworks? I look at an application framework as being able to provide additional or extended functionality to improve the quality of applications built from it.

There are a variety of out of the box frameworks, such as Spring (or Spring.NET), etc. I find that the largest problem with these being that they are not a la carte. Basically, they have too much functionality and unless every piece of that functionality is the best implementation available, chances are that you will end up using a patchwork of multiple frameworks to accomplish these tasks - causing bloat and confusion. This applies to free and commercial systems, in my opinion.

Of course, writing is largely re-inventing the wheel. I don't think it is without merit, though, as it provides the most customizable option. Some things are just too large to develop, though, and seem to be poorly implemented or not implemented at all in this case because of the hesitation to commit to the upfront costs of development.

There are a large variety of open source projects that address individual portions of a could-be application framework as well. These can be adopted or assimilated (obviously depending upon license agreements) to help frame in a comprehensive framework from diverse sources.

We approached the situation by looking at some of the larger concerns in our applications across the entire enterprise and came up with a list of valid cross-cutting concerns and recurring implementation issues. In the end, we came up with hybrid solution that is partially open source, partially based on existing open source options, and partially custom developed.

A few examples of things that are in our framework:

• Exception and event logging providers. A simple, uniform means by which every application can log exceptions and events in an identical fashion with a minimal coding effort. Out of the box, it can log to a SQL Server, text file, event viewer, etc. It contains extensibility points to log to other sources, as well.
• Variable assignment enforcement. A generic class that exposes extension methods based upon the object type, using a syntax that is inspired by JUnit. For example, to determine if myObject is not null, we can do a simple Enforce.That(myObject).IsNotNull(); or determine if it is a specific type by doing a simple Enforce.That(myObject).IsOfType(typeof(Hashtable)); Enforcement failures raise the appropriate exception, both reducing the amount of code and providing consistency in implementation.
• Unit testing helpers. A series of classes, based upon reflection that can automatically test classes and their properties. (Inspired by Automatic Class Tester from CodePlex) but written from the ground up. Helps to simplify the creation of unit tests for things that are traditionally hard or time-consuming to test.

We have also outright adopted some other functionality, as is. For example, we are using PostSharp for AOP, moq for mocking, and autofaq for DI.

Just wondering what other people might have done and what concerns your framework addresses that you did not find tooling that you were satisfied with? As for our experience, we are definitely reaping the benefits of the new framework and are content with the approach that we have taken.

From stackoverflow

• My simple advice is that you use a framework that suits your needs. Of course, in order to do this you have to experiment and know beforehand what are you looking for. Even if the framework comes with much more than you need, what is the cost of this? For the average problem, the cost is only a few extra Mbs in a jar, which I think is OK for most projects.

  In the end, you should choose a framework that does the job right, so that your focus is at providing user value and easing the maintenance of the developer. Of course, there isn't a single framework that addresses everyone's problems, but there are some frameworks that hit the sweet spot on what they aim for. It's all a matter of going with the best compromise.

  joseph.ferris : Exactly. That is why we went with the approach of finding as many pieces to the puzzle as possible and built around them.

• Our approach was to devote an entire team of architects (namely 'Technical Architects') for:

  • either adapting existing open-source framework, in some case encapsulating them in an in-house API in order to be able to change framework should the need arise
  • or creating new framework based on the specific needs found a several teams for several projects.

  Whatever the approach, those frameworks need to be very well documented (at least with a complete public API), and their release need to be well advertised:
  Since all teams will based their work on those frameworks, they need to upgrade their versions of framework as soon as possible, in order to build their own deliveries.

  joseph.ferris : That is very similar to what we are doing and the requirements that we have. The only difference is that I am the "team" of tech archs saddled with the task. ;-)

  VonC : Impressive! Good luck with that :)