DevExpress Newsletter 11: Message from the CTO

23 September 2009

My Message from the CTO for the eleventh newsletter:

Common Codebases

The topic of "common codebases" came up in a conversation: "Is it possible to have a common codebase for similar controls that target different platforms?" My answer? Of course.

The common codebase idea is a good one and something we've been doing for a long while (though we tend to call it informally an "engine"). Our charting product XtraCharts, as an example, uses a common engine across WinForms, ASP.NET, and WPF, and we'll be porting it to Silverlight for completeness. The engine is responsible for maintaining data about the chart (labels, legends, etc), calculating chart information based on the various series of data points, and so on. There are then platform-specific presentation models for displaying or rendering the chart.

A similar structure is present in our reporting product, XtraReports. The printing engine not only loads/saves report definitions and is instrumental in creating a report, but it is also responsible for exporting the report to PDF, DOC, XLS, and the other formats we support. Each platform (currently ASP.NET, WinForms, and, partially, WPF) then has some specific presentation classes to render the report for preview.

Ditto our scheduling products, XtraScheduler and ASPxScheduler, share common code for maintaining and tracking appointments and resources, and this will be reused in the Silverlight/WPF versions.

In fact, talking about Silverlight and WPF, the presentation model (XAML) is almost identical (or can be limited and viewed as such), so it makes sense to write Silverlight/WPF controls in tandem, sharing a much larger common codebase than is possible, say, with WinForms and ASP.NET (which use totally different presentation models). Again, something we're taking advantage of.

Having a common codebase does require some discipline to design and keep the engine "common" across the platforms supported. In a way, it can be viewed as layering the control in a similar manner to how we layer an application into presentation, business, and data tiers.

Although the code reuse benefit is vital, there are drawbacks too. Using such common code will tend to produce more assemblies, for example. Also, you can no longer have platform-specific releases since changes to common code will affect all platforms (luckily this is not an issue for us, since we only release DXperience as a gestalt, all platforms at once).

All in all, I think having a common codebase is an admirable goal, one which we'll continue to target.

As an addendum, only yesterday, during our weekly conference call to discuss R&D progress, yet another example of this came up: it seems the WPF team discovered much common functionality between "docking" and "form layout". So, they're busy adding a form layout component (think XtraLayoutControl for WPF) by first factoring out the common code from DXDocking. It's a little too late for that for our WinForms products though — there would be too many breaking changes at this stage.

Still it's fascinating that the layering we're all pretty much used to in the context of an application can also be done in the context of controls, even when targeting many platforms.

Free DevExpress Products – Get Your Copy Today

The following free DevExpress product offers remain available. Should you have any questions about the free offers below, please submit a ticket via the DevExpress Support Center at your convenience. We’ll be happy to follow-up.
Josh Einstein

That is so cool! The WPF product suite is really maturing. Forms in WPF have been the biggest pain point and between the features in the latest release of the WPF grid and this new form component, I think I need to re-up my subscription.

I've been working on something myself but it's not at all polished for public consumption and has virtually no designer support.!89E05724AF67A39E!860.entry

23 September 2009
Sebastià Prat

Cool! It seems to be quite difficult ;)

Just one idea, if we make much more assemblies the startup time of the applications will increase. For instance using XAF


23 September 2009
Lester Garcia

I think one of the icons that we use a lot and is quite out of synch is the Grid. Coming from Delphi all the way to Silverlight, it is evident it needs attention since they seem to not even share the same philosophy. Taking for example the Details, they work in very different ways in each platform and in Silverlight is implemented through the preview feature.

I am glad to hear that the concept of code sharing is key to DevExpress but as in my example I would go even to the customer experience level.

23 September 2009

I think what you mean by common should be clarified.

A common code base is good so long as it has functionally related code, but causes unnecessary coupling if the code is grouped because it does the same thing but to functionally different things.

24 September 2009

I'm a big fan of that concept.

I have made a few apps where I work, and they all rely on a common infrastructure called SIP.

It requires AT LEAST one codebase assembly (SIP.dll) that only depends on System, System.Core and System.XML and holds common functionnalities and interfaces. It has a very small memory footprint.

In turn, this assembly is used by other codebases assemblies that are more platform/engine-oriented, such as WinForms (SIP.Win), services (SIP.Services), ASP.NET websites (SIP.Web), reporting (SIP.Reports), data browsing (SIP.Data), Windows CE (SIP.Mobile), Google services (SIP.Google), Microsoft interoperations (SIP.Microsoft), and so on.

After that there are more specific codebase assemblies (SIP.Data.SqlServer, SIP.Microsoft.Win32, SIP.Google.Maps), who only depends on the namespace below them...

... and THEN comes the "real" application's assemblies. It has a similar structure (App.Data, App.Web, App.Win, etc...) for different versions of the same application on different platforms. They all depend on "App.dll", which in turn depends on "SIP.dll".

It took a while to build the infrastructure (around 50 different assemblies only for SIP), but now that it's up, everything I build around it is WAY more robust, stable and easy to develop and maintain.

It's the best investment I've ever made in my career.

24 September 2009
Joe Hendricks

It is very reassuring to see the consistency through the years at DevExpress - I never worry about future incompatibilities because you are always one of the first companies to adopt Microsoft's newest technologies. - Joe

26 September 2009
John Newcombe
John Newcombe

I agree with Crono, I follow essentially the same development paradigm.

.Net makes it easy to separate logic into different assemblies for maximum reuse.

29 September 2009
Patrick Wolf
Patrick Wolf


reusing the internal plumbing code between different UI's is definitely an important step...

Another very important step is to make the API's for the end-user (developer) as much as possible interchangeable so that we can switch between a Silverlight and WPF frontend just by switching a few assemblies (or at least minimize the changes as much as possible).

This might also mean that the namespaces would need to be adjusted so that a docking component for Silverlight and one for WPF really end up having the same API in the same namespace.

Thanks for considering it,


20 October 2009

Please login or register to post comments.