3 Silverlight Architecture Tips with Brad Himelstein

Recently, I dove back into XAML-based development to create some Silverlight plugins for a large web application. Most of my experience in XAML came from writing a WPF application from 2008 to 2009, so I had much to learn about the asynchronous data retrieval paradigm used in Silverlight. I had questions about UI Design Patterns, Service-Oriented Architecture (SOA), and how to reuse class libraries, so I asked Brad Himelstein, from CinCom, if I could pick his brain while we hit a few golf balls. Brad has continued working with Silverlight and WPF for a few years, since we worked together on the aforementioned WPF application.

Below is a summary of his tips as well as some quotes from our conversation.

Tip #1: Use Model View ViewModel (MVVM)

Me: “Do you ever use any sort of patterns for the UI?”

Brad: “MVVM”

Me: “I am just now getting introduced to that. What are the benefits?”

Brad: “It is great, because you just setup the data context and do all your databinding, and it just magically works. Two-way binding works as well.”

Brad identified additional benefits during other parts of the conversation. MVVM’s primary purpose is to separate the concern of the behavior of an application from that of the user-interface design. It is a practical implementation that is cleaner to understand and easier to pass back and forth between designers and developers versus the default approach of placing logic in code-behind files. He provides sample MVVM source code here.

Tip #2 Extend Proxy Classes with Shared Custom Code

In my application, I use WCF RIA Services to query server objects and return them to the Silverlight client. This technique simplifies the process of retrieving service data and populating local objects because a local proxy object is created and populated automatically. In Brad’s words, “If the web service returns an object of class ‘Foo’, we don’t need to redefine ‘Foo’ in the Silverlight app.”

Unfortunately, I had a great deal of logic included with the retrieved classes that I also wanted to be able to use in the client. I asked Brad how to elegantly work around this limitation of Service-Oriented Architecture.

Me: “What I was hoping to get with RIA Services was, say I’ve got some class I’m returning from the service. I can load it with data easily but I have additional calculation properties on this class, such as FullName, which is just a property that returns FirstName and LastName concatenated. A local proxy object is created automatically for use in Silverlight, with data populated for FirstName and LastName, but the proxy does not retain calculation logic. Since I have a server-side object that has calculation properties defined, how can I share that code for use with the Silverlight client and the proxy object?”

Brad: “If you know you’re going to use FullName, then just create another string called FullName and set the property on the server so it is passed down to the client in the object, because it is not going to take those calculated properties and bring them down.”

Me: “But then that FullName would have a state when it returns.”

Brad: “Remember, you can extend everything. So on the client side, you can alternatively have your own Foo class, which can be used to extend the partial Foo class that is returned from the server.”

Brad’s suggestion was enough to help me come to a solution that fit my needs.

Partial Class Extensions

Let’s use the sample Class “User” to continue our example from above. In such a class, I can place fields of the User, such as FirstName and LastName in one file named User.cs. User class should be defined as a partial class, so we can combine definitions of the class from 2 separate files. Hence, in another file, named UserCalcs.cs, we should define calculated properties, such as FullName. At this point, the server behavior will work as it always would have if we had just implemented all properties and fields in the one file. However, the Silverlight client would not yet know about the FullName property.

Shared Files

An important limitation of Silverlight is that it can only reference projects that are compiled as Silverlight projects. In other words, Silverlight cannot natively reuse definitions from standard .NET class libraries. What it can do is recompile normal .cs files into a Silverlight assembly.

To do this, right-click on the Silverlight project in your Visual Studio solution and click Add Existing Item. Navigate to the file that contains the calculated properties, UserCalcs.cs. Click the file, and then click the down arrow next to the Add button. Choose Add As Link.

The Silverlight project will now compile this partial class definition. It will extend the proxy class as well as the server side class from the same file. Therefore, maintenance of those calculated properties can be shared between the client and the server side code from one file.

Tip #3 Learn HTML 5

Ok, Brad didn’t actually say this so bluntly, but it was a recurring theme of our discussion. Based on recent information about upcoming Windows (8) releases, Silverlight’s future is unclear. From what I have heard, Microsoft is committed to version 5 of Silverlight (current release is 4) but has made no guarantees beyond that. Windows 8 will have 2 versions of its Internet Explorer 10 browser: tablet and desktop. The tablet version will not allow plugins, like Flash and Silverlight. Some have summarized the decision by stating that from Microsoft’s standpoint, Silverlight is “no longer strategic.”

Still, the death of Silverlight development, especially in corporate environments, is distant. Here is a great Microsoft client decision workflow about the correct technology to leverage based on your needs. I believe it reinforces the idea that even after Windows 8 is released, new Silverlight applications will have their place.

Lastly, even though Windows 8 tablets will not allow Silverlight plugins to be loaded within its browsers, native Windows 8 tablet apps will be developed using WinRT. As Brad informs us, this gives us Silverlight developers hope, as WinRT is still “just C# and XAML.”

By Nathan Stuller+