h1

Silverlight as the View of Full-Trust applications

May 31, 2009

I recently read a great post by Ward Bell on “multi-headed” platform development…making your app work with WPF and Silverlight.  This is a topic that is of interest to me in the enterprise setting…and I have done a little playing around with it.  I left a long-ish comment on his blog with an idea that I’m hoping to get feedback and opinion on, and so though I’d repost here with the possibility of getting other’s ideas.

Wards post is here: http://bit.ly/Swy1n

Here’s my thoughts:

In business apps, generally the argument for writing something in WPF is to have the local access to services (printer, hardware etc), not to get “3D” and other WPF niceties. Silverlight 3 (IMO) is ready for LOB app development…more than ready.

— IDEA —

So, if that is the case (which I believe it is), for the “I need a bar code reader” type scenarios I’m considering an approach where you “host” SL within a rich-client container, and through a JavaScript bridge access your full-trust code which is locally installed. You app is installed locally, you have full-trust assemblies, so can do the local manipulation of the system or access to printers, scanners, barcode readers etc.

[NB: This is not the same as the FIT client install, because your getting access to a full-trust installation that you setup. The FIT client install is still in the sandbox]

This would essentially boil down to having the local, full trust container look-n-feel like a service endpoint…you’d be making calls to methods by serializing parameters (via DataContract) and passing them through JS as strings. Far from this being a down-side, I could see how this might force good architectural design…ensuring the UI really is View…and not tangled up with stuff that should be there.

Now, the hypothesis (unproven at this stage) is that the effort of setting up this container (once) would be less than the ongoing development friction and maintenance woes of cross compilation and incompatibilities that Ward describes. You also get the ability to use the same UI (or parts of it, if it’s nicely modularized a la PRISM) in the browser – and instead of accessing the local-full trust code via the JS bridge you hot-swap to calling a web-service.

I would love to hear people either beat up on this idea and tell me why this is crazy, or offer other opinions and insights.

I’ve done a bit of dual-WPF/SL development (mainly building out PRISM examples) and it’s has a bit of a smell to it. I’m optimistic that a surgical containment strategy may be a smart move? What do you think??

Leave a comment