XAF and Acropolis

A recent post to our XAF newsgroup is asking the following question: "How does this eXpressApp Framework differ from Microsoft's Acropolis framework?"

The question implies that the difference is somewhat hard to spot, and yet it was my first reaction to think that they are really nothing alike, and accordingly the difference should really be very obvious. I guess the truth is somewhere in between the extremes, as usual, and so it takes a bit more thought and effort to find the answer to that question and describe it in an understandable fashion.

There are a number of different angles from which this problem can be examined. First of all, maybe we should all go ask Microsoft a similar question: "how does this differ from XAF (or a bunch of other, vaguely similar producs out there)?" After all, they are the ones reinventing something that tries to occupy a market which is already occupied pretty densely, as well as displacing CAB, which until very recently used to be worthy of sessions at TechEd.

Secondly, we didn't consider the differences between Acropolis and XAF, or even CAB and XAF, when we started the project - simply because none of those were around at the time. Of course we have re-evaluated the market since those days, but the fact of the matter is that there isn't a single feature in XAF (yet?) that is positioned to mimick something that's also in these other products, or even to compete directly with any of them.

Now, these thoughts bring me to the point where we find the actual differences. It's all about priorities, functionality and being a lazy programmer.

(I've said it before and I'll say it again: being a lazy programmer is a good thing because it makes you want to find ways to do your work more quickly and more efficiently. If you need to justify this to your manager, try mumbling terms like "time to market" or "team velocity" in between the shouting.)

Think about it this way: why have we all evolved - well, many of us - from Win32 API programming in C to .NET Framework based programming in OO languages like C#? There are many answers to this question, but they all involve priorities (most of us earn money through programming these days, so finishing an application is more important than creating a global Windows hook to insert another button in an Open File window title bar), functionality (we've recognized that in the majority of cases it's more useful to have communications functionality available in the framework than to be able to m_lpFolder->EnumObjects(m_hWnd, SHCONTF_FOLDERS | SHCONTF_NONFOLDERS | SHCONTF_INCLUDEHIDDEN, &penumFiles)) and being a lazy programmer, which kind of summarizes a healthy attitude that often makes us do the right thing with regard to efficiency.

With this background - what's the difference between XAF and Acropolis? Not surprisingly, it is that both products have rather different priorities and functionality. I can't say whether the Acropolis programmers are lazy, but I can tell you that ours have taken their laziness to a new level, resulting in fantastic efficiency for themselves and XAF. Acropolis focuses on WPF UIs. Full Stop. They do have some extensibility in place to support adding reusable functional parts to the framework, but they are definitely not promising to provide these parts. They mention that other UIs can be used, but they are very careful not to promise to provide these either. It might sound sarcastic, but one of their most important priorities seems to be not to promise much functionality apart from the UI itself.

XAF is different. We do lots of things that Acropolis doesn't have on the menu - let's see, in no particular order, and certainly not exhaustive:

1. XAF supports multiple UIs - not just theoretically, but really, out of the box.
2. A very simple summary of what XAF does is "it creates a full data management application for you based only on a single class declaration per data type". I don't think Acropolis even tries to make a claim like this.
3. XAF has loads of functionality in the package - think of runtime UI customization, Reporting, Validation and the Security systems, to mention functionality on a variety of different levels.
4. XAF is largely based on mature components and libraries. Data storage is provided by XPO, which has been around for many years and targets more than 10 different database backends. The Windows Forms components (and some of the ASP.NET ones - we'll be  improving on the current status in that area soon) as well as printing, reporting and export support are extremely feature rich, having been developed for years as well. Acropolis doesn't have anything to compete with this.
5. I feel pretty safe to promise that XAF will be supported for many years, in the worst case. Of course we will deliver the source code once the product is final in a few months. In contrast, what are you going to do with Acropolis today? It's not shipping, in fact it's pretty far away from shipping. And the whole CAB/SCSF/Acropolis thing doesn't look good to me either, certainly not very future proof.
   

So how about this summary: Acropolis is a framework that allows others to implement application functionality in a modular way. Once it becomes available and 3rd parties do their thing and provide the functionality, you might be able to use it as an efficient way of creating business applications - perhaps, although not very likely in my opinion, even as well as you can with XAF. I don't believe you'll ever reach the same degree of integration that XAF provides, nor probably the same high level functionality. Certainly you can't get it now. Most probably you won't be able to get it in 2008.

As I said, it's all about priorities and functionailty, and well, yeah, being lazy. Remember, it's a good thing.

Free DevExpress Products - Get Your Copy Today