Constraints included - considerations on framework structure, architecture and evolution

Somewhere on a forum, I found people engaged in a discussion about various business application frameworks, and somebody commented (paraphrased): "XAF is probably not the right choice for us, as it seems constrain us too much with regard to applications we can build. The technical documentation describes a particular path that has to be followed in order to create an XAF application."

(Btw, this comment is paraphrased and not attributed to anybody because I don't have a way of finding out whether the original poster is fine with having his comment published and discussed here, together with his/her name.)

Well, this comment baffles me. Let's have a quick look at various hypothetical frameworks to see why:

1. Alma Knack, a C#/Windows Forms programmer who needs to prototype many new applications, feels that some of her work is redundant. So she creates a little library that makes it easier for her to create new applications from scratch. Most of her applications have splash screens, so she has a helper class for that. She takes the prototypes to other people and customizes them right there, so she also writes a feature that lets her change form layouts at runtime and import the modified layouts into her development code later. Since her applications are otherwise very diverse in nature, there's really not much more she can do. When she's tasked with creating a prototype of a little Tetris clone for Windows Mobile, to be given to customers as a gift, she can't reuse any of the code in her library.
2. Tad Pohl is a programmer in an insurance company. They have many different departments that work with custom applications. Of course there's always a large part of the functionality in any one of these applications that accesses common data, so Tad uses a common data access layer and many standard data layouts which he created for his two target platforms Windows Forms and ASP.NET. Since he's an OO fan, he structures his library well, which makes it quite easy for him to create the additional data views required by each of the departments. Of course his framework is specific to his domain of insurance data - creating an application for the HR department requires him to write almost everything from scratch, but then he doesn't normally have to do that.
3. Hugh Mungus is the lead developer in a company that specializes in SOHO productivity applications. Other teams in the company work on various applications for Windows Forms, ASP.NET and lately WPF and Silverlight. Many of these applications interoperate with Microsoft Office, Excel Services, SharePoint and SQL Server. Hugh's team works on a framework of data display and manipulation functionality for typical small business needs, and the framework can also create data bound Word and Excel documents and publish to the various server solutions. The new requirements of WPF and especially Silverlight represent a great challenge to Hugh, and a special requirement of a data mining feature that needs to access an Oracle database is almost impossible to implement for him.

So what can we learn from these scenarios?

1. Every framework is created for a particular purpose.
2. The functionality that's included is that which is common in the majority of applications the framework needs to cover.
3. The functionality that is *not* included is that which needs to be implemented specifically for most or all of the applications.
4. A framework is designed to make a particular task easier by providing ready-made solutions for the typical parts of that task.
5. There are always problems out there that a particular framework can't solve easily.

Okay. Now, does XAF constrain the types of applications you can build with it? Yes, of course it does. Or no, of course it doesn't. Hm... which one is it? Well, to give an example: the typical XAF application works with data in a database. If that's the type of application you want to create, then XAF is going to help you a great deal. But does it mean that you can't create applications that don't use databases? No, it doesn't. Only if you do that, then XAF won't help you as much.

Look at Windows Forms. If you want to create applications that have a typical main window, then Windows Forms makes that quite easy - you just derive your own form from System.Windows.Forms.Form, pass it to Application.Run and you're done. If you want customize something small, then you'll be able to hook into events or write method overrides in the form class to do it. If your form is supposed to be triangular in shape, have color effects in the background, a hole in the middle and shouldn't react to the mouse, then you might still be able to do it, but it gets more complex. If you want to run a secondary UI thread for your splash and status windows, that's when the standard mechanisms begin to fail and you have to do quite a lot of work yourself. If your application is Doom and you're using Windows Forms because of the nice MessageBox class, you've probably made the wrong decision entirely.

Back to XAF. The docs describe a particular way of creating an application that saves you as much work as XAF is able to save you. It is the most efficient way of creating an application if your basis is XAF, and if you want to use all the functionality the framework provides. If there's some part of the functionality that you don't want to use, that's typically easy - just deactivate it, or never call it. If you want to customize the built-in functionality, there's quite a lot you can do by way of options, custom pattern implementations and so on. If you want to replace certain parts of functionality with your own implementations, there are extensibility points that enable you to do this, and since our own modules aren't different from the ones you can create, we are pretty confident that custom implementations will work just as well.

What does that baffling commenter want us to do? Broaden the scope of applications that can be created easily? No, I don't think so - the phrase "it constrains us" doesn't seem right then, it should be "doesn't currently include that functionality". Of course broadening the scope of applications XAF can target is always something we work on anyway.

Second guess, does he want us to describe different paths of creating XAF applications, ones that don't take advantage of XAF functionality? Weird idea... why would we do that? Sounds like then we're back to basic ASP.NET or Windows Forms programming, and it's not our task to document that. Oh, we do write documentation about circumventing standard XAF features all the time - there's content on creating custom editors based on third party controls, for example, and I've recorded a video on extensibility of the ASP.NET application just recently. Of course there are a million things somebody might want to do in place of the standard features, so we're not likely to finish documenting them all anytime soon.

Third guess, he wants to create his application in precisely the same way as he's always done it, only he wants it to be easier. Yeah. Well. Perhaps a framework isn't really the answer then.

Generally speaking, there are certainly things that we need you to buy into in order to use XAF. Everybody who's ever created a framework knows that there are lots of small decisions to make on the way. We've made all those decisions, keeping things as flexible as we could along the way (which is probably something that Alma, Tad and Hugh above wouldn't do, since their situations are different), but still, we've made them. If some of these small things are really big for you and you don't agree with our solution... well, there may be only so much we can about it now, but please do let us know, it will make XAF better in the long run.

Bottom line: if your project doesn't need the functionality in XAF, don't use it. If the solution doesn't fit the problem, don't use it. It sounds simple, but it seems to be a word of wisdom these days. *cough*Ribbon*cough*Silverlight*cough*Astoria*cough*

Free DevExpress Products - Get Your Copy Today