Constraints included - considerations on framework structure, architecture and evolution

XAF Team Blog
03 July 2008

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*

Tags
10 comment(s)
Linton
Linton

"(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.)"

Oliver, Once they've posted their opinion--it's fair game--whether they're "fine" with it or not--esp. when it's an uneducated opinion. Thanks for the comments.

Secondly--

Am I misinterpreting your repetitive, spasmodic contraction of the thoracic cavity, by associating the Ribbon, Siverlight,  and Astoria with future XAF features?

3 July, 2008
Oliver Sturm (DevExpress)
Oliver Sturm (DevExpress)

Linton,

Well, they didn't publish their opinions on *our* forums...

Ribbon - yeah, it's in 8.2. Silverlight and Astoria aren't going to be in XAF in the near future. We'll see if they come in somehow over time.

3 July, 2008
Nate Laff
Nate Laff

sweet zombie jeebus! ado.net data services, eh? why.. that would mean WCF functionality was improved. excellent...

3 July, 2008
Nate Laff
Nate Laff

ah crap. just read oliver's comment again. it's a fine line between "are" and "aren't"

3 July, 2008
Alex Hoffman
Alex Hoffman

>>> "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."

Frameworks are always suited to various solution types and scenarios.  Sure you can argue, that you can do anything with it - it's all .NET and you get the source code right?  But that doesn't really help does it.

@Linton - its not me, but I find the "uneducated opinion" jab at the original comment's author unpleasant.

3 July, 2008
Ruy
Ruy

Hi! Oliver,

First of all, let me congratulate you!  XAF is really Fantastic! I watched 'Gerry and Oliver' videos and I liked very much! I think they are extremely useful! specially for me, because I'm not an expert in software development. I hope more videos are coming!

Today I was reading your post, and I understood (sorry if I didn't understand well - my english is terrible!) that you were trying to show us that we can use XAF to create others types of apps (different from DataBase apps). I agree. Although the focus of XAF is for DB app, I think that for those programers that knows XAF well, it is much better to use XAF than start the app from scratch! There are a lot of things in XAF that probably can be used in any app.

In XAF documentation (Overview-Scenario #3)  I read '...If you are trying to build an application of another type - a game, a graphic editor, a word processor, etc. - the eXpressApp Framework won't help you. ...' Is it really true? I guess XAF may also be an excellent tool to build a standard MDI Text Editor, for example! Am I wrong?

It would be a great help for us, if someone from your team, could provide a MDI standard sample app, like RibbonSimplePad.exe in XtraBars Demo using XAF. I want to use XAF in every project that it is applicable.

Thanks!

Ruy

3 July, 2008
Oliver Sturm (DevExpress)
Oliver Sturm (DevExpress)

Ruy -

I guess the truth is somewhere in the middle. XAF doesn't prevent you from writing an MDI text editor, but since this is not one of its primary targets (maybe not even among the secondary ones, to be honest), it just doesn't do much for you if that's what you're trying to do. The further you get away from the primary target of a framework, the more of an obstruction the framework might actually present - iow, at some point it would be easier to not use the framework at all.

A sample of an MDI app? Included in the Demos folder. A sample of a text editor? I don't think that'll happen...

4 July, 2008
Vadim Katsman
Vadim Katsman

Somewhere in the fading history there was MFC.  MFC was something phylosophically similar to what DX is now - the set of tools and wrappers around Windows SDK (CWnd etc.) and a framework (document-view archiecture and so on).  Even they have few classes to assist with the database development but fortunately for all of us they never pursued anything beyond UI.

What I understand about XAF, it is a jump from the collection of WinForms controls to the handling of architecture for all layers of the application bypassing the fundamental need (unfilled, and more in the core of DevExpress product line) - UI framework - the framework assisting implementing common UI problems (MDI application for example) abstracted from the business rules layer/tier and data access llayer/tier.  It is perfectly OK to have another framework to link business rules and data access layers and maybe the unified application framework that cover all tier oriented frameworks but ...

... is that possible to use XAF in the capacity of UI framework only and still benefit from its architecture and implemented pieces?

Or I am wrong all along and XAF is not the UI framework at all? and I am missing another DevExpress offering that provides implementation of common UI patterns?

11 July, 2008
Oliver Sturm (DevExpress)
Oliver Sturm (DevExpress)

Vadim,

XAF is not a UI pattern framework - it implements UI patterns of course, and even more than one, but they aren't surfaced in a way that would make it supremely easy for you to select one and make it work for whatever type of application you want to create. As an example, the document/view pattern in MFC made it easy to create applications that looked like Word, and I guess that's one of the reasons why MS never implemented that pattern in other frameworks again (like WinForms) - after all, it's a minority of people these days who implement applications that look like Word, and for data related applications, which the majority works on, document/view isn't as useful.

I think the whole comparison with MFC is interesting, but rather academic. The world has changed, the underlying framework WinForms is much more powerful than MFC in many ways (while it does lack some specific features, agreed), and of course with ASP.NET and WPF there are other frameworks that have a different structure entirely.

Part of XAF could be called a UI framework, sure. But there's another big part that assumes your data is stored in a database (and there are many consequences of that assumption, such as data being visualized in grids and detail views by default), and of course there's a lot of functionality included that is based on that same assumption. I don't think it would be too difficult technically to create an application with XAF that uses the UI patterns (automatic view creation, model configuration, multiple UI targets, ...), but doesn't use any of the other functionality. Would it make much sense to do that? I'm not so sure.

Does DevExpress provide a product that has implementations of common UI patterns? Like document/view? Or like standard layout main forms? No, we don't. Of course one could argue that some of our controls actually make this so easy that they are a "framework" in their own right - like our BarManager and related configuration components in  XtraBars, or the XtraLayout Control, for example.

14 July, 2008
Dan Arnold
Dan Arnold

I think that XAF would gain much wider acceptance if there were documentation that is not formatted as standard Visual Studio hyperlinked help.

In other words, more of a text (PDF format) that strives to explain the extensibility points in the prouct and actually builds a reusable module with controllers and example views.

The videos are so superficial in content, that anyone whom has read anything about the product, or used it to build an application AT LUNCH TIME, already has that knowledge.

They are more like merketing pieces, than tutorials.

I relize the product isgoing to change rapidly, but, if you want more wide spread acceptance. Write documetation that is formatted more as a book than autogenerated hyperlinked API

dpocumentation.

We hould not have to spend hours hunting through your knowledgebase to find out how to use the product.

The reason I am so passionate about this request is that I dont want tot see the product fail. And as you add Windows Workflow Foundation and Dependencyy Injection type features, in my opinion, you will need to write the book on XAF.

I hope someone there is listening. I have read several posts on oogle about how great your controls are, but that the documentation is the worst, compared to your competitors.

I there any hope of getting this kind of documentation?

20 July, 2008

Please login or register to post comments.