Just in time for the release of Silverlight 3, I’m bidding farewell to Silverlight on my current project.

I’ve been working with Silverlight for about a month, and despite my best efforts it became clear that my project was just not going to come together the way I’d hoped. Thus I pulled the plug on Silverlight, and switched back to ASP.NET MVC and Dojo. Interestingly, I was able to re-build all the existing functionality in less than one day – things go fast when you’ve got a lot of experience with a technology!

I made this switch for a number of reasons, not the least of which was simple pragmatism – I was making relatively little progress with Silverlight, and the application did not really “require” Silverlight per-se.

I had chosen to to use Silverlight for a number of reasons:

1) The promise of ADO.NET Data Services (aka Astoria) to streamline the Data Access service layer

2) The promise of XAML Data Binding and/or DataForms to simplify client-side form management.

3) Prism’s promise of an easy to use, testable, application model with clean separation of concerns.

What I found is that while each of these features is really killer on it’s own, actually rolling all of them together is non-trivial. Learning all of these technologies while trying to build a large application (more than 50 data entry screens and lots of business logic) was just not viable. I’m sure if I had a team of 3 developers, and we had 6 months to get up to speed on XAML, ADO.NET Data Services / RIA Services, Prism, Commanding, XAML Data Binding, and Silverlight Unit Testing, then this application would merely be “challenging”. Since my team and I have built multiple similar apps using ASP.NET MVC and Dojo, there are significantly fewer “unknowns” as well as a ton of existing code we can leverage.

So, as I bow out, here are some thoughts about Silverlight…

Silverlight itself is pretty cool, but the tooling for Xaml at Silverlight 2 was harsh at best. The Xaml intellisense in Blend3 is a big improvement in the work flow. Designing the UI’s took a little getting used to because you don’t really have all the Windows or HTML form controls. Thus a fair bit of time was spent just getting up to speed with what was viable.

One I got a handle on what I could do in the UI, it was time to figure out how to build the application itself. Prism (Composite Application Guidance for WPF and Silverlight) is really cool, and there are a lot of intro level posts and videos out there. From what I can see, this is “the” way to build a “serious” Silverlight application. However, unless you’ve got a solid handle on Xaml, and DataBinding in WPF/Silverlight, it’s not easy to sort out how the View separation is supposed to work in non-trivial situations (i.e. taking commanding beyond simple buttons).

Additionally, there is lots of talk about Model-View-ViewModel as “the” design pattern to use, yet the Prism guidance does not show any examples of this (it focuses on Supervising Controller and Presentation Model). The best resource I found for M-V-VM in Prism was David Hill’s Prism quick start kit and sample app. The sample app is still pretty simple, but it is M-V-VM, and you can follow what’s going on. If this was extended to show best practices integrating ADO.NET DataServices, creation of client side proxy classes implementing INotifyPropertyChanged (needed for Two-Way data binding), it would be an awesome resource. Along those lines I did come across some T4 templates that facilitate creating client side proxies that actually support Two-Way databinding (on a side note, the next release of Astoria will have updated client proxy generators which will include INotifyPropertyChanged)

Also the Prism Reference implementation mixes both of these patterns in different areas of the app, which makes it difficult to keep things straight. Not to pick on the reference app, but it also side-steps the issue of talking to “real” services by just stubbing the services out pulling from static, client-side data sources. It would be really good to have some example code that’s calling back to ADO.NET Data Services over, oh, I don’t know, let’s say Northwinds

Managing resources in Prism projects was also confusing. If you want Blend to see your resources (mainly images in my case) they need to be in the assembly containing the module. However, I could not sort out a clean way to then have those resources move over to the Shell assembly and thus make their way into the xap file. I ended up simply having copies of all my images in both my module assemblies and the shell assembly. Not ideal, and I’m sure there is a good way to handle this, but it was the least of my concerns.

Another thing I struggled with was that my UI was going to be pretty complex – the final app will have over 50 screens. The UI Composite capabilities of Prism would be nice to use, but given that we are an Agile shop, we don’t do big design up front. But, the regions need to be defined in the Shell at the beginning of the development cycle. I sense some problems down the road with this. Additionally, in order to decompose the Views and ViewModels into convenient pieces I would like to have different sets of regions in the app. I’m sure that the patterns & practices guys could work a way to make that happen, but it sure was not clear to me how to whip that up.

Summary

Overall, it was an interesting journey, and I’m planning on building a much simpler resource planner application using Silverlight in my spare time. I intend use Prism on it, and give that it’s much smaller (4 screens) I think it will be a better starting point.

On a side note for the GIS people reading this, I never really got to the point of using the ESRI Silverlight control in this project. The few demo apps I’ve built with this control would indicate that it will be just as easy to use as any other Silverlight control.

Note: This applies to Prism v2 with Silverlight 3 Beta.

So I’ve added a button into a column of my DataGrid, and I want to bind in the Click handler to my ViewModel, as well as pass the selected item into said handler.

I’m not going to go into the details of Commanding in Prism at this time (maybe later), but here’s what the xaml looks like:

...

<data:DataGridTemplateColumn Header="Details">
    <data:DataGridTemplateColumn.CellTemplate>
        <DataTemplate>
            <Button Commands:Click.Command="{Binding Path=Value, Source={StaticResource ViewDetailsCommand}}"
                    Commands:Click.CommandParameter="{Binding}"
                    Cursor="Hand"
                    Content="Details" />
        </DataTemplate>
    </data:DataGridTemplateColumn.CellTemplate>
</data:DataGridTemplateColumn>

...

The Click.Command is a little out of the ordinary in that the Binding Path is set to Value, and the Source is a StaticResource on the control. There are a few hoops to jump through on this, but the Prism reference implementation application (RIStockTrader) does show how this works.

What had me scratching my head was how to send in the object which represents the current row in the grid. All of the examples looked like this:

Commands:Click.CommandParameter="{Binding Path=ItemId}"

Which is great when you just want to send the Id of the item in. But in my case, I want the actual object so I can send that to the "Details" form for editing. In hind sight it’s obvious that you would set the CommandParameter to the "Binding", since that’s the item itself, but it was one of those things that you don’t think would make sense.

Anyhow – through the power of Google, I hope this saves someone else some time/frustration.