From ASP.NET to Silverlight in Five Leaps

Posted in ASP.NET, Silverlight, Tagged with

There are a few differences between ASP.NET and Silverlight beyond the API that require a subtle shift in gears before you can really jump in and start working. Here are five you might find useful to know.

Leap One: Your server isn’t listening (to the browser)

You’re used to considering a request to the server for an ASP.NET page as a single movement from client to server and back again. The markup you prepare is the template from which a fully expressed page is returned to the user’s browser.

With Silverlight, the user’s request to your server is for the entire client-side application code in compressed format. This is the binary ‘.xap’ file that appears in a compiled Silverlight project’s ‘ClientBin’ directory. With this request fulfilled, there are no more contracted operations that need to occur between your server and the user’s browser.

Now, this isn’t to say that you won’t want to make a web service call to your server from your Silverlight application, such as when you want to authenticate a user against a traditional ASP.NET Membership provider, but this is officially the end of a request/response architecture that provides a single response for every URL and any state that is passed to the server either through server-side ViewState, Cache, Context, or the query string.

Leap Two: A client is a client is a client

ASP.NET has the concept of a client, but the client is the browser and we don’t code inside it. The ASP.NET code you write never runs on a client, it is executed on the server and its end result is served as HTML, CSS, JavaScript, images, et al., which are interpreted by the browser and displayed to the user. You don’t have to “program” anything on the browser, you program the server to create the necessary markup (like a script) for the client, and if you’ve done your job you see the expected results.

Silverlight requires you to think in terms of clients as consumers of your server-side data, which also contain code that executes to handle the end result of the data it receives. You have two applications to write now. Rather than processing the user’s view on a server, you’re much better served asking a server through a service call for some data, and then rendering that data through code executed right on the client’s desktop. This means you have to think about performance in two places. You don’t just care how fast and efficient your server delivers data, but the implications of doing complex things with that data on the Silverlight client application. You had to care about performance on the browser, of course, but the limits were well-known and not up to you.

Leap Three: Silverlight is not .NET

ASP.NET runs on the .NET Framework on your server, where you can bring the whole framework to bear (with some partial trust exceptions) to solve your problem. Similarly on the Windows platform you can use WPF to create extremely rich user experiences with a full complement of flexible classes. Open source projects, blog posts, magazine articles, and books; if the code is in .NET, chances are you can leverage it.

Silverlight is a sub-set of .NET, but it is not .NET. In fact you can think of Silverlight as a really large copy-paste job with some very large missing pieces. Silverlight has its own mscorlib.dll, and many other analogs. If you think of Silverlight like “.NET running free on the user’s computer”, you’ll be disappointed. Because it’s designed to be lightweight, quick to download, and not prone to the security nightmare “.NET running free on the user’s computer”, it’s missing a lot of functionality you may take for granted, or other classes you rely on use under the covers. There’s no compression. There’s very little in the way of serialization. Reflection is decidedly limited to public methods and to the reflecting classes. You can duplicate some of the missing functionality but you’ll be trading off against download times, a challenge faced by any public-facing web application.

Leap Four: Silverlight is readable on the client

In ASP.NET, with some effort you could be reasonably sure that while a user could do anything they wanted with the markup you generated on the server, how that markup was created, and the process to manipulate it, was a closely guarded secret on your server. In short, “View Source” didn’t scare you, because the source was merely the fruits of the server’s labour; you didn’t have to send the whole orchard when the apple would do.

Although it’s easy to think of Silverlight as a one-time transmission of application logic (thanks to the first leap), you have to remember that you’re sending the entire client application as code (the second leap) to the user. Similar to how anything you send to the browser, whether it’s JavaScript, CSS, or image files, is freely available to those who know where to look, so too are your Silverlight assemblies. This time, however, you’re dealing with real client code which, if not obfuscated, may provide more information than you’d care to share with savvy web users. There are obfuscators available for .NET, though they can be cost prohibitive for individual developers (I’m not aware of any open source obfuscation tool for .NET, though this would be a welcome discovery). You can ease the risk somewhat by making sure you keep the most sensitive information hidden on the server, but your UI tricks will remain in plain view.

Leap Five: Your entities are not entities

While I can’t guess your preferences for handling data transfer between your classes and a persistent store, I can guess that many of your web applications running on ASP.NET enjoy the separation between server and browser in the form of unrestricted access to the classes that represent the business you’re solving. It is possible to have the object that contains data from the database be the same object that you interact with in code before persisting back to the database again.

Silverlight applications of any complexity will ultimately have to work with copies of your objects (or perhaps copies of your DTOs which are copies of your entities), because they come in the form of a proxy to the real thing, facilitated through contracts, such as WCF serialization. Since a Silverlight application must only consist of other Silverlight assemblies, it makes sense that you’d have to effectively duplicate all of your classes on the client, have no server classes at all, or represent those classes somehow with a proxy. This carries with it the challenge of making sure you send those proxies back from the client to sync up with the real deal on the server.