Author: Nikhil Kothari’s Weblog

"Those Who Ship, Win!"

This used to be written on a giant poster in the hallways of building 42 (original home of the .net framework) … should have taken a picture of it while it used to be around. (missed classic photo opportunity – anyone have a shot of it?)

Today, we delivered one of the most important features, shipping a v1. Yes, WCF RIA Services v1 is done, and shipped! You can get the final build along with the final build of Silverlight 4 tools, right here on the RIA Services landing page, that also has links to blogs, tweets, docs, forums and all things RIA Services.

It has been an exciting ride building this technology from the ground-up, seeing people use it live even with early preview builds, and providing tons of feedback (thanks), and bringing credibility to Silverlight as a line of business application platform. It has also been an interesting learning experience for me personally in many dimensions.

The diagram below captures the essense – what can a framework do by redfining a Rich Internet Application as a single logical application that spans across client and server, and consumes as well as provides data and services. My original Vision to Architecture blog post still holds up a year or so later. I’ll be doing a follow-up to that post, as well as updating my Book Club reference app with a couple of new features, so stay tuned.

[Full post continued here…]

Earlier today, my SilverlightTV recording on RIA Services and Validation went online. I used validation as a feature area to focus on this first recording on RIA Services, because I think it illustrates both the RIA Services value proposition and key elements of the vision around the project in a very direct manner. Specifically:

• Focus on end-to-end solutions for data scenarios. It is not sufficient to just address querying data or submitting some changes, but about providing the infrastructure for managing data, editing with validation, tracking errors raised on client and/or server, rolling back changes, and more.
• The server project and client project are logical halves of the same application. It would be great to preserve and propagate developer intent, and semantics from the database to the middle tier to the client, and share code across tiers where possible. In other words leverage intent and rules as close to the end-user, while enforcing them at each tier. Automatically.
• Provide out-of-box solutions to common scenarios. The Entity class on the client provides a pretty complete implementation of working with data on the client. It provides identity management, change tracking, change notification, transacted editing and rollback capabilities, as well as tracking and surfacing validation and concurrency conflict errors. In particular, in the context of this post, Entity provides an implementation of infrastructure interfaces such as INotifyDataErrorInfo introduced in Silverlight 4, so you don’t have to roll your own.

In my demo for SilverlightTV, I used a product catalog and product editing scenario (my favorite scenario if you ask folks on the team). However for MIX10, I used a Book Club scenario, which I think is quite a bit more interesting (with the potential to become my new favorite scenario).

Check out the video. And then come back to read further. My MIX10 summary post lists everything else going on in the Book Club sample (along with a link to all of the sample code), but the rest of the post focuses on the validation aspects.

Update 3/26/10: For those looking for a copy of the app demo’d on the SilverlightTV show, you can download the Store sample.

[Full post continued here…]

It looks like I have a set of posts on ViewModel, aka MVVM, that have organically emerged into a series or story of sorts.

Recently, I blogged about The Case for ViewModel, and another on View/ViewModel Association using Convention and Configuration, and a long while back now, I posted an Introduction to the ViewModel Pattern as I was myself picking up this pattern, which has since become the natural way for me to program client applications. This installment adds to this on-going series. I’ve alluded to this topic in the past, but it is now time to focus and dedicate a post on the interactions between a view and its view model, i.e. the arrows in the diagram below:

I like to present ViewModel as something that is not brand-new, but a simple refactoring of [most of the] code-behind into a separate class so that the logic is decoupled from the user interface. This class simply employs the basic OOP constructs that you might have encountered in CS101 – it encapsulates state and behavior, exposed via properties, methods and events.

As simple as properties, methods and events…

All view models will encapsulate some interesting application state or data, exposed as properties, usually, in an observable form, i.e. properties that raise change notifications. Almost all view models will also expose some operations, ideally exposed as vanilla methods. And finally, some view models will also raise application-specific notifications as events.

Declarative glue…

A view is then responsible for consuming and working against the object model exposed by its view model as it presents information, and collect and react to user input, gestures etc. The data-binding engine in Silverlight makes it natural to bind to the properties in one-way or two-way fashion. Commands (in the UI, not in the view model – will address this below) allow invoking operations, usually in response to some user input or external inputs (eg. a timer or GPS input). Finally triggers allow the view to listen to events and translate view model notifications into user interface actions. All of these serve as glue expressed in XAML via declarative markup.

This is captured in the diagram above. Bindings are fairly straightforward and you’ve more than likely used them if you’ve done any Silverlight programming. So I am mostly going to focus on commands and triggers, but first, lets see this pattern in action.

An example application…

As always, an example helps make things concrete. I converted Tim Heuer’s translation/text-to-speech application to follow the view model. In doing so I used the latest release of Silverlight.FX – while the ViewModel is an abstract presentation, it is useful to pick up a framework that allows you to quickly get started with your application, rather than build the plumbing from scratch.

On the right is a screen shot of the application. It is also now included as part of a series of sample applications packaged with Silverlight.FX. You can dowload the latest version (v3.5) by visiting the project page. I’ll have a Silverlight 4 version that takes advantage of new capabilities, but in the mean time the Silverlight 3 version should continue to work. The sample application here uses v2 of Microsoft Translator API, which now has support for not just translating text, but also converting text to speech for a specific set of languages. You’ll need to get an API key and update the web.config in the sample on your end to run the application.

The class diagram of the view model highlights the interesting things going on in the view model:

In terms of application state, it exposes the text to be translated, the resulting translated text, the list of languages, and whether the speak operation can be performed. In terms of operations, it provides the ability to perform translation, or to speak (as in produce the audio stream) the translated text. Finally in terms of notifications, it lets its associated view know when that audio stream has been loaded and is available for playing.

[Full post continued here…]

At MIX10, I presented the Developing with WCF RIA Services Quickly and Effectively talk. For the demos I used a BookClub application – the scenario is a team application for team members to use to share books and browse/search/request shared books.

The following are the concepts that the demos and code cover:

[Full post continued here…]

One of the comments I got on my last post on view/view model hookup options was the following:

I’ve been a mvvm fan but actually when I see all the hoops to jump through I wonder at times how effective this is

So I wanted to take a moment to list what I thought compelled me to adopt the ViewModel pattern of client application development (so much so, that I now feel odd writing Silverlight and sometimes even Ajax apps in any other way). Some will be obvious benefits, especially to those already using MVVM in their everyday development, but I want to throw in a couple that are farther out exploratory ideas that I am thinking about. I’d also love to pursue what it means to make view model more mainstream, so if you’ve got ideas on this topic of "Why ViewModel", I’d love to hear.

The often cited benefit is increased testability of additional code within the application, and I’ll get to that, but I think there are some other benefits that are more applicable, considering not everyone practices the rigor of the level of testing we’re talking about here. Essentially, testability is not a justification for the ViewModel pattern on its own.

[Full post continued here…]

Some time back, I blogged about different options to hook up a view to its view model when following the ViewModel (aka MVVM) pattern. There are multiple approaches in use out there. I raised the possibility of a convention-based approach in addition to existing ones like the ViewModelLocator pattern.

Motivation: I find the simplest way to explain ViewModel is to present it as a better code-behind, especially to the mainstream developer who is intimately familiar with the latter (at least in the .net world). With the code-behind approach the UI, its state and operations are all mixed up. The ViewModel pattern is of course designed to help separate application logic from the view, but now results in two discrete halves that need to be reconnected. Result: additional concept count. With a convention-based approach, I believe the simplicity of the code-behind model can be achieved while preserving the ability to decouple.

Like most other convention-based systems, it addresses the common and mainline scenarios well. There will always be some more advanced or less common scenarios that will fall out of the convention, for which a configuration-based approach needs to exist alongside.

With that context, I want to share what Silverlight.FX (@silverlightfx) now offers around hooking up a view to its view model by following a convention over configuration approach, to provide simplicity while retaining flexibility.

[Full post continued here…]

A bit about my RIA Services talk at MIX10… let me know what you’d like to see.
[Full post continued here…]

In the ViewModel, aka the MVVM pattern, a view such as a UserControl is bound to its associated view model. The view model manages state exposed as observable properties, operations exposed as methods and raises notifications via events. An interesting question is how a View should specify its view model, and how a view model instance should be created. Like everything else in the ViewModel pattern, this topic is no different. There are different strategies, with pros and cons, and different people have different opinions.

In this post, I’ll describe a couple of options, and hope to collect some feedback as well as ideas on alternatives. Part of my goal here is to improve what is supported in Silverlight.FX out-of-the-box. The other goal is to find what resonates, and see if I can collect input on suggestions I’d like to make for future ViewModel support in Blend/Cider – so any thoughts you share will certainly help. Looking forward to hearing them…

My general criteria for evaluating each approach is the following:

1. It should be possible to create the view model through an IoC container, so its dependencies (properties, or constructor arguments) should be satisfiable. In other words, its likely a view model can’t be instantiated directly in XAML… at least not in the subset of XAML supported by Silverlight today.
2. The mechanism should not interfere with designability either in Blend.
3. Furthermore, the mechanism should even lend itself to designability. For example, the data-binding picker should allow binding to properties on the view model.

[Full post continued here…]

Starting a new link listing series around interesting posts/content related to RIA Services. Hope you find these useful, and if you’d like to share something please send them along…
[Full post continued here…]

The long-awaited event (by some) … an updated script# build, along with next steps, new channels for Q&A and staying up-to-date via @scriptsharp on twitter…
[Full post continued here…]

In my post on RIA Services: From Vision to Architecture, a while back (right after MIX09), I mentioned that I like to think of RIA Services as RAD for RIA. At that point we had a very early preview of framework bits with little tools support. A large part of jumpstarting your development actually centers around good tooling. VS2010 brings tooling for RIA Services (now: WCF RIA Services).

Scott Hanselman demonstrated some key features used in building a Contacts application (as shown on the right) during the keynote at PDC09.

The latest version of RIA Services is now available for download. It works on .NET 4 and VS2010 as well. You can also check out a video tutorial on using RIA Services and Visual Studio 2010.

In this post, I want to highlight the range of tooling features that span from the start to getting an application up and running.

[Full post continued here…]

Lots of wow from this morning with Silverlight 4 (and RIA Services) taking center stage in the keynote, here at PDC09.
[Full post continued here…]

Immediate thoughts after Ray Ozzie’s keynote at PDC09
[Full post continued here…]