XAF - 7 - Take advantage of the UI abstraction

This is post no. 7 in the mini series "10 exciting things to know about XAF". You can find the announcement of the series here.

As you know if you've had a look at our XAF pages or tried the product yourself, there's a layer in XAF that allows you to develop applications for the Windows Forms and the ASP.NET UI platforms at the same time. All your code can live in the UI independent module and XAF takes care of the UI specific representation. Of course there are lots of cases where certain UI specific changes need to be made, but this is also easy to do within the solution structure, because it includes projects that specifically target each of the supported platforms.

Reaching this degree of UI independence we have was an important target for XAF from the beginning. Of course there will always be platforms that people use at the same time -- i.e. it makes sense sometimes to have a version of an application that runs on ASP.NET and another one that uses Windows Forms --, but we also make our product and the code you write on the UI independent level a much safer investment.

The world around UI technology evolves pretty quickly these days. As an example, it's not too long ago that Windows development was focused on Win32. For many use cases, Windows Forms abstracted enough from that old world to make things a bit easier for developers, but WPF is really the first UI platform that doesn't inherit an API that is, in parts, more than 15 years old. Still, from a Microsoft developer's perspective, the time that passed while Windows Forms was the primary platform of choice for client development was already considerably shorter than the ActiveX period that came before it (or the Delphi period, if your that way inclined). Personally I do believe that WPF is going to be very significant for an extended period of time, but if we have a chance of abstracting our business development efforts from these uncertainties, why not take it? Regardless of what your thoughts are on WPF, Windows Forms, Silverlight, ASP.NET, UI specific software factories, AJAX, the whole old web vs client discussion.... wouldn't it be great not to have to consider these things anymore?

Perhaps we can't promise that all these issues will be entirely irrelevant to your development forever. No, we certainly can't promise that. But what we're trying to do is, once again, to save you significant effort by doing a lot of your work for you.

Abstraction from the UI doesn't come for free. It has a price in two different areas: (1) abstraction and (2) working with a least common denominator as a feature set. To an extent it is possible to make abstraction comfortable to use, and it's also possible to enlarge the common feature set by making the abstracted technology more intelligent, basically leveling the playing field by filling in gaps where necessary. Of course this latter approach also means that any new UI platform will be harder to target, depending on the gaps it has. It is, and will always remain, a fight for the perfect compromise.

In real world applications there are several different scenarios where it makes sense to have UI abstraction:

• You need the same application to run on two different platforms. For instance, you could have a richer native UI that people use locally, while others access a web UI from outside the company.
• You have slight variations in the two UIs, for instance in the case where the "external" version of your application, using the ASP.NET UI, doesn't have all the same features as the "internal" Windows Forms based one.
• There are two very different UIs in use, but both work against the same objects/database and business logic. An example of this would be a web system with a Windows Forms management frontend. In this case you would probably have to/want to design the web frontend in a non-standard way, as far as XAF is concerned.
• If you create UI modules or UI based functionality for a particular vertical solution, you can create this domain specific functionality in a way that enables it to be used on two UI platforms -- by your customers or other departments in your own company.
• You can implement certain generic functionality in your application on the UI independent layer.

There are classes in the DevExpress.ExpressApp.Editors namespace that allow you to access common functionality of UI elements without actually introducing UI dependencies into your code. The MainDemo included in our XAF distribution contains a few controller examples (in the Module project) that use these classes to provide common functionality -- clearing fields in a detail view is one such example.

I didn't put it many links in this post, since I believe this is more about the general consideration of whether or not, and when, UI independence makes sense. As I said before in another post -- in the end it's your choice. XAF also lets you create projects specific to one of the supported UI platforms, if that's what you prefer. My personal belief is that UI abstraction is moving from a convenience to a necessity these days, and that belief is well reflected in the way XAF works.

Free DevExpress Products - Get Your Copy Today