This post is part of my PDC09 Conference Notes series. These are my raw notes taken while watching the various session videos from PDC09. Refer to my original post for some conventions I tried to use.

PDC Session Link: Networking and Web Services in Silverlight

This session went over the different ways to expose data to a Silverlight application. Data access requirements for Silverlight was grouped in two ways and presented as the following graphic:

Each example fell somewhere on the X/Y axis of the chart above. Resource Centric was explained to be CRUD operations, while operation centric was more behavior driven.

Forms Over Data

The first examples were your typical forms over data applications, which are Resource Centric and follow a Request/Reply model.

If you control, and have direct access to the data, then RIA services was recommended. Aside from a short demo, not a lot of time was spent on RIA services, as there are other presentations that get into the details.

Another option for when you control the data, is to use WCF Data Services, which exposes your data in a RESTFul manner that adheres to the open data protocol (OData). In addition to data you control, services like SharePoint expose the data contained with-in via the open data protocol as well. The advantages to using OData sources over public REST services, is that more is known about the data, so you get a better development experience.

If you are working with a public data store exposed with REST, and it’s not OData, then use the enhanced (for Silverlight 4) ClientHttp library. It has a good programming model, and a lot of the deficiencies in previous versions have been solved. For example there is now support for Basic HTTP Authentication secured with SSL.

2 Way and Streaming

The second group of examples looked at duplex and streaming scenarios. The first example was a chat application which is an operation centric example that has some request/reply elements, but mainly users a duplex model. WCF was the recommend technology to support the duplex model. The included binary encoder provided a 71% performance improvement over the standard text encoder, even over HTTP. Binary has been the default encoder since Silverlight 3, but is only useful when both endpoints are .Net applications.

Duplex itself can be setup in your WCF bindings in one of two ways. For internet scenarios, you will need to use an HTTP binding, which is a polling based duplex model. While not present in the beta that was released at PDC, there are plans to enable HTTP Chunking, which would allow for multiple messages per HTTP request to increase performance. For intranet scenarios, you can use the NetTcp binding for the best performance. Remember, since this is WCF, you code once, and just change your bindings as needed.

Silverlight 4 supports UDP multicast, but it is pretty much an intranet only solution, as your network must be configured to support UDP multicast.

There is a new Silverlight TCP Socket Policy server project template in the online template gallery (accessible in VS 2010). This makes it very easy to setup the policy server to allow cross domain socket calls for your Silverlight application. An enhancement being considered for Silverlight 4 is that if the application has been elevated, then you will not need to worry about policies.

This post is part of my PDC09 Conference Notes series. These are my raw notes taken while watching the various session videos from PDC09. Refer to my original post for some conventions I tried to use.

PDC Link: Advanced Topics for Building Large-Scale Applications with Microsoft Silverlight
Presenter: John Papa (@john_papa)

The title of this presentation is a little misleading. It could have just as easily been titled, best practices for building line of business applications in SilverLight. The concepts, if not most of the code can be applied to WPF as well. There was a lot of talk about Prism, which I have not looked at in great detail. However, as a result of this presentation, I will take a closer look at it once I get around to working with SilverLight and WPF more. John pointed out several times that you are able to pick and choose what parts of Prism you want to use, which at least makes it sound a little less invasive then some of the other things to come out of Patterns and Practice.

A similar framework which is not developed by Microsoft is Caliburn. Which one is better, is probably open to debate, and both are continued to be developed. John did mention some gaps in Prism, which he developed some code for (posted via his blog), but perhaps these are available in Caliburn. If you are just starting out with SilverLight or WPF, I would suggest looking at both frameworks. If you are already using one or the other, I don’t know how much sense it would make to switch, but I always like to keep my options open.

MVVM

The first part of the presentation was focused on defining MVVM, or the Model, View, View-Model pattern. The primary benefit of the MVVM pattern, is that is allows for good separation of concerns, which leads to increased testability and maintainability. As you can see below, a lot of time was spent on describing the View-Model and how it fits in, while the View and Model are fairly straight forward.

• View: Responsible for rendering the UI only
• Model: Contains your domain entities (i.e. customer, order and order details)
• View-Model:
  • Handles the communication between your View and Model thru bindings, commands, events.
  • Responsible for providing everything (data) a particular view requires.
  • Sometimes your View-Model will look almost identical to your model. Other times, it will contain a mash-up of various entities as required by the view.
  • Ensures that your view knows nothing about your model, and that your model doesn’t known anything about the view (or require references to view related dependencies)

Three ways to implement MVVM were presented. I had never considered the first two, while the 3rd one is where frameworks like Prism, Caliburn, Ninject (Inversion of control) come into play.

• ViewFirst (Static Resource): View Model can be created as a static resource in the view. This tightly couples the View Model to the view, but gives you the best experience when using Blend (referred to as blenability)
• ViewFirst (Code Behind): The view is injected to the View Model constructor. Since you loose the blendability, I’m not sure why you would pick this over option 3.
• View + View Model Marrige: Use a intermediary to marry the View and the View-Model together. Again, you loose blendability, but this is the approach that everyone takes when using Prism, Caliburn or a home grown framework.

When creating a SilverLight application using MVVM, there are some common functionality that you need to implement, which is where Prism and Caliburn come into play. Since this session used Prism, I will list what was shown, which was limited to what Prism can offer. I expect that Caliburn offers a similar set of functionality.

• Shell: Container for all UI modules, such as menus, windows etc.
• Regions: Shell is made up of regions which control where UI modules are displayed.
• Modules: Separate code modules that can be developed in isolation and then loaded by Prism. Modules can talk to one another thru event aggregation (I wonder if MEF would be a better choice)
• Event Aggregation: An eventing model that allows for cross module communication.
• Commands: SilverLight 4 adds support for commands, so it is my understanding you do not need to use Prism’s command support anymore.
• Bootstrapper: Controls application startup and configuration. Configure your IoC here.
• Delegate Command object for use with commands (very simple class to create if you are not using Prism)

Commands:

• Invoke an event on your view and have your view model respond to it.
• When you invoke a command, you expect a response.
• Commands work out of the box well with buttons. However you need to create new command objects that implement ICommand for use with other controls. John puts these objects in his Infrastructure dll, and I think he may have provided some of this code on his blog.
• I still have a lot to learn on commanding