DevExpress Newsletter 11: Message from the CTO

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