Architectural Best Practices for Silverlight 2.0

these will or could change when people that are smarter then me publish material I'm sure but in my work on everything from the emmy site for the SL 1.0, lauch or Crossfader for the BG keynote, or innovate on or msn or the mix 08 stuff etc this all seems to be a nice bulleted list of best practices for Silverlight 2. we will see what happens when there is a Silverlight 3.o so with much ado:

Underlying Silverlight architecture helps us abstracted UI from logic and we need to take into account this toolability story that Silverlight enables as this can provide more ROI and shorter time to market for application development if designers and developers can work at the same time without the whole ‘through it over the fence’ approach. From a design pattern standpoint I recommend pMVP or Proxy Model View Presenter as the ‘better’ design patterns I know of require more upfront development as Silverlight doesn’t support the underlying infrastructure for these patterns. pMVP keeps it simple and the simplest solution is usually the best.
For Architectural best practices lets bullet out our best practices:

· Design Pattern pMVP (Proxy Model View Presenter) which is a clean, simple design pattern to implement that gives better abstraction.

· Make use of designer developer workflow enabled by Xaml UI separation.

· Don’t impose artificial Xaml coding conventions on designers or yourself as this slows productivity. Just let Blend go with it.

· Agree on Naming conventions, coding conventions (maybe standard WPF conventions might be a good place to start) and the like as you like but be consistent so that it is easier to support and pick up again later. This improves readability and helps the whole designer developer interaction.

· For the most part doing event bindings in Xaml, the more in Xaml the better however use common sense. If the designers are using Photoshop and converting the Xaml maybe just do the bindings in code so that you can have the designer just do a new conversion to generate new Xaml if they might make changes.

· Build at lest the Presenter logic in a separate Silverlight library.

· Build generic custom controls in a library.

· Consider putting the presenter code in a separate library or at least its own folder.

· Build Views with Blendablity in mind. Break up complex user controls that build the View into its component parts so that the elements can be more easily worked with in Blend.

· Use Gobal Styles and Templates and other resources in the App.xaml only when they are truly global in the application. Don’t clutter up the global resources with elements that are not really global.

· Use best practices with other connected technologies such as WCF or SQL or IIS/ASP.NET. Best practices in Silverlight wont’ do you much good if everything else is a mess.

· IF you build controls that rely on the DOM bridge encapsulate the ECMA related resources either in a Xap or right into the control so the ‘user’ as the simplest method to use the control.

· Consider the install experience to encourage users to install Silverlight so they can use your Silverlight application. Just using the default badge is boring.

· Consider Search Engine Optimization if it is a public site, such as control element names and the HTML on the Silverlight page etc. event the names of Xaml elements as a lot of this will be in the Xap that will at some point be parsed by search engine spiders.

That gives us a nice list of best architectural best practices. Following these simple rules lets you approach Silverlight architecture and application design with ease. Now we didn’t go into a lot of the application ‘Design’ aspects of ‘Designing’ applications such as UML etc but the focus here is strictly on Silverlight.