Weblog Home Page
Welcome to my blog! On this page you'll find the most recent posts on Silverlight, ASP.NET, photography, and other random thoughts and opinions.
If you are looking for older posts, check out the archive pages. Or you can also subscribe to my RSS feed.
And while you are here, check out my photo gallery and projects page...
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.
[... 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.
[... continued here]
My MIX10 talk was published a little while back - as you might expect, its on RIA Services:

Developing with WCF RIA Services Quickly and Effectively
WCF RIA Services provides an end-to-end framework for creating n-tier, data-driven applications on top of Silverlight, ASP.NET and WCF. This talk demonstrates how you can use the framework and tools to get started quickly while focusing on your business logic rather than on plumbing and infrastructure. This talk goes beyond the basics to demonstrate how you can use RIA Services effectively to create well-architected solutions that employ best practices, advanced techniques and integrate key application patterns such as ViewModel (aka MVVM) that enable you to scale your solution on the server and across presentation and data technologies, and to create great user experiences on the client.
What would you like to see covered? If you have any thoughts, please share. If it fits with the general flow and time, I'll try to include it. Or it might make for seeding the Q&A...
I'm planning to skip the drag/drop style demo. I think folks have seen that, and get it that RIA Services jumpstarts your application. What do you think? Or is it useful doing a quick introduction? For most of the talk, I am planning to pick a few key patterns and best practices that I believe are indespensible when building real-world n-tier applications, and using the technology effectively. ViewModel (aka MVVM), as mentioned, is one of those patterns, but it isn't the only one. I'm going to pick between 3 and 5 such patterns to fit into the session.
One thing I really love about RIA Services is how it brings together different technologies making up the broader Web platform. Hopefully some prototyping I am currently doing will materialize into a nice exciting demo... fingers crossed.
T-28 days... see you at MIX!
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:
- 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.
- The mechanism should not interfere with designability either in Blend.
- Furthermore, the mechanism should even lend itself to designability. For example, the data-binding picker should allow binding to properties on the view model.
[... continued here]
A number of WCF RIA Services team members are starting to blog about RIA services features introduced in the bits we handed out at PDC09. It is also great to see other folks working with the bits and sharing their experiences over blogs and twitter. Here is a list of some of the new posts in the last week or so that I found interesting:
Data Access in DomainServices
- POCO Types and Associations: Yauhen Safrankou describes the use of the [Association] attributes when you create your own POCO types. RIA Services is designed around vanilla CLR types, so you can plug in several DAL technologies, including your own types.
- Amazon S3 with RIA Services: speaking of broad DAL support, Mark Woodhall blogs about a sample of access buckets and objects in the S3 store in a DomainService.
- Entity Framework v2 and RIA Services: EF has many great improvements in v2, making it suitable for n-tier development, and [http://blogs.msdn.com/digital_ruminations] Mathew Charles describes some things you want to keep in mind when building your data models.
DomainService Patterns
- DomainService Error Handling: Mathew describes how RIA Services honors the ASP.NET CustomErrors feature to prevent sending errors and sensitive information to clients across the trust boundary and how you can centralizing error processing and logging on the middle-tier.
- Composition Support in RIA Services: Mathew has been busy blogging about new features. This one discusses our feature for handling classic scenarios like Orders-OrderDetails (and similar aggregate scenarios). And yes, the feature works for hierarchies that go beyond two entity types.
- Presentation Model in RIA Services: Deepesh Mohnani describes another new feature that allows you to craft up your own DTOs or presentation tier types for exposing from the middle tier instead of exposing DAL types directly. RIA Services allows you to use your types in both read-only and read-write scenarios.
- WCF in WCF RIA Services: Saurabh describes what is behind the name change for the product. RIA Services still provides simplicity and a prescriptive model, still takes care of default services infrastructure, but also brings the full flexibility and power of WCF when you need to dive to take control.
What is in the works? (sneak peek at what is coming)
- Silverlight 4, Async Validation and INotifyDataErrorInfo: Fredrick Normen describes using a very important addition to Silverlight 4: an enhanced IDataErrorInfo. Now that this is in Silverlight, we’ll be adding support for this on the Entity class so you get an out-of-box exception-less validation story that automatically supports displaying and tracking both errors raised on the client as well as async errors raised on the server without requiring you to write infrastructure code. Something to look forward to…
If you're new to RIA Services, stop by the official landing page, which has install links, and intro videos.
If you have a RIA Services related link to share, feel free to send me a note via my contact form. This quick post was to get the series started; I am hoping to make this link listing a weekly thing, to share what I find interesting around RIA Services.
I’m also on twitter where I share updates much more often. You can follow me via @nikhilk.
Finally, an updated Script# build. Woohoo!
Its been all too long since the last update, leading folks to wonder if the project is still alive. I liked to think that the project had simply reached a temporary plateau of a stable release that was functional and usable for a core set of scenarios. Indeed some of the largest Ajax applications at Microsoft like the Office 2010 Web Applications and many others are now built from C# source code compiled to JavaScript, helping large teams of engineers work everyday with large codebases over the course of long product cycles. However, what I am learning is that it is also essential to continually have some set of updates to ensure there is sign of life and progress.
So this post will provide an update of where things are at. First and foremost, the project is by no means dead. In fact the interest level in the project has only just picked up a bit.
Build 0.5.5.0
This is mostly a bug fix release, but there are some interesting fixes, and a couple of small changes. I'll list a few notable ones (the release history page has more details).
- Removed the $ shortcut, which was conflicting with prototype and jQuery.
- Fixes to scriptlet code editor inside Visual Studio so code is no longer truncated (scriptlet code is now persisted as sibling .scriptlet files - eg. Foo.aspx.scriptlet represents the script code-behind for Foo.aspx). Scriptlets only depend on sscorlib.js now (don't depend on ScriptFX framework anymore - first step in making them work more broadly with fewer dependencies)
- Fixes to bitwise comparison expressions, and equality/inequality checks
- Fixes to release minimization in a variety of scenarios
If you're new to Script#, check out the project site, and the readme. Download the bits and give it a shot. And be sure to check out the samples that get installed as well for more concrete ideas.
If you've been using Script#, feel free to send me more information about what you've built, esp. if it qualifies for showcase material (I need to revamp that), or comments about what you'd like to see. I'll also use a poll from time to time to guage interest and guide future developments. In fact, I've got one now about what sort of IDE support you'd like to see - Visual Studio 2008, 2010, or Visual C# Express? Right now it seems folks most want 2010 support. I wasn't planning on 2010 support until VS2010 was out of beta, but looking at the early results of the poll so far, I've decided to go ahead and add an installer for that in addition. So with 0.5.5.0 you also get 2010 support!
Got questions?
I am planning to use stackoverflow rather than spending time building a dedicated forums. Lets see how that experiment goes, and whether it works out. Simply post your questions tagged with scriptsharp. I'll try to monitor them, and hopefully there will be folks in the community who can also pitch in with their experience.
Next Steps - Build 0.6.0.0 and beyond
The next build will see some bigger changes. This is sort of an heads up. From a functionality perspective you're going to see two things happen:
- The MSAjax support will grow to include support for all the new APIs coming out as part of ASP.NET Ajax. Aacorlib.dll (the equivalent of mscorlib) will be called mscorlib.dll (which should make FxCop happy), and MicrosoftAjax.dll will be broken out to match the different individual script files making up ASP.NET Ajax.
- The MSAjax mode of script# has been less functional than the native Script# mode (using sscorlib). Using an extension script to add missing functionality on top of the ASP.NET Ajax scripts, in 0.6, the modes will be nearly identical. So if you're using the MSAjax mode, you'll benefit from array instance methods, delegates, ability to use foreach etc.
Beyond 0.6, the list is interesting and long - generics, scriptlets for ASP.NET MVC, jQuery support, polishing up the unit testing infrastructure couple of teams have built, and streamlining the IDE experience etc. etc.
On-going updates and communication
I've been on twitter now for some time, and it makes it much easier for quick updates than the blog posts. As such, I've set up a twitter account for Script# specifically, that I'll use for announcements, quick updates, as well as the direct or brief conversations, and occasionally post a question targeted at Script# users. Follow @scriptsharp to stay up-to-date ... oh and feel free to follow @nikhilk too while you're at it :-).
If you've got a deeper question that isn't suitable for twitter or for stackoverflow-style Q&A, then please use my contact form to reach me. I'll get back as soon as possible.
Enjoy! And if you hit any unexpected issues, do let me know... in case I need to put out an incremental quick fix release...
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.
[... continued here]
Wow! Just Wow. That about sums up the Silverlight 4 debut during ScottGu's keynote, here on day two of PDC09. The demos were killer, and what is even more amazing is how much progress has been made in delivering new capabilities in just a few months since the release of Silverlight 3. And of course, RIA Services got some first class exposure in the context of Silverlight 4 ... RAD for RIA. More on that in the next post.
There is no substitute for checking out the keynote video, and the killer demos, one after another… quite literally. Check it out once its online. I'll pick out three of my favorite demos that I especially want to call out.
Web cam, microphone and device access - the ability to get the raw input stream (video, audio) and data from external devices/peripherals is going to unlock all sorts of new scenarios, for collaboration, scanning documents, and bar codes, and creating fun consumer experiences.
HTML Integration - now Silverlight apps can tap in into all the HTML content out there, and not only display HTML in an interactive browser control, but also use HTML content as a brush to paint any Silverlight control. The demo featured the Bing page alive within the Silverlight application, and then used to paint a set of pieces in a puzzle game.
 
If that wasn't enough, whats possible is Silverlight hosting HTML hosting Flash, that is playing a video, while the live rendering is broken into a zigsaw puzzle, that can be put together using touch input. Whew!
RIA Services - Silverlight has many features that make it real for business applications, including printing support, drag/drop, right click, and copy/paste support. However the highlight (ok, I'll admit, I am biased) is the story around the ability to work with data end-to-end, perform queries, submit changes, perform validation, etc. by way of WCF RIA Services takes Silverlight beyond just consumer facing experiences and into Line of Business scenarios. Here is a link to the Contacts app.
Of course, the highlight was the end-to-end application: Facebook on Windows implemented as a trusted, out-of-browser Silverlight application. Great visuals, smooth animation, nice integration with Facebook APIs, ability to work with photos, videos, the news stream, as well as raise notifications and integrate with USB devices plugged in into the computer. Simply wow. The application will be available as a reference sample. Something to learn from. Looking forward to that.

Silverlight brings a combination of just the right set of things for the next generation of rich internet application development - powerful, yet small runtime, a simple web deployment model, sandboxed execution with ability to go beyond the sandbox when needed, and a great set of core frameworks in terms of data, communication, presentation and fundamentals. V4 makes all that so much more compelling.
The best thing yet... you can start exploring and playing around with the beta bits today. Check out the tutorial videos that have already been posted. Looks like I need to start looking into providing a version of Silverlight.FX that uses some of the new Silverlight 4 features. I also really want to jump into and start writing a real end-to-end app that builds on these exciting new possibilities. Excited!
As usual, I find Ray Ozzie's keynotes inspiring and optimistic about where software and services are headed. PDC09 was no different. The central theme in the presentation was that of three screens (desktop, phone and TV) and the cloud, and how these come together to offer seamless integration and convergence of technologies for the consumer.
For a developer, what Microsoft brings is a consistent experience developing for this broad platform with Azure on the back-end, Windows, Internet Explorer and Silverlight on the front-end, .NET, Visual Studio and Expression as the framework and tooling.
There were some very cool demos. The new Silverlight-based Seesmic Twitter client seemed refeshingly different, and promises to become a developer platform in itself. The OData-based access to public data, turning data into services has the potential to democratize data and serve as a catalyst for innovation.
All that is cool! However to me the real takeaway, was what came at the very end. We're seeing the early days of cloud computing, and that it is time to dream, and dream big, and that developers play a key role in unlocking the potential, and turning that into applications, services, and solutions.
.NET RIA Services relies heavily on metadata annotations for expressing intent beyond what can be inferrd via convention. For example, validation rules on entities and members can be declared as annotations, which then enable a variety of consumption scenarios. We also have metadata for describing model aspects in DAL-agnostic fashion, and hints for automatic UI-generation. What we have today is just a first step.
The general design we're enabling is actually quite flexible. For example, a number of developers want to have metadata specified external to their code, for example in XML files or in a database. Some don't like attributes, and have asked for a fluent interface instead. In RIA Services, we wanted to create a consistent API for consumers to lookup metadata. In short the CLR metadata API, or the TypeDescriptor API from component model. And we want to let producers or specifiers of metadata choose a persistence store or specification mechanism that meets the needs of their scenario, as long as they can surface attribute instances when needed.
In fact, we have an over-arching vision for a metadata pipeline (which I'll get to later in the post).
However, the first concrete experience developers have with our metadata model when adding validation rules and UI hints, is unfortunately not very pretty. The out-of-the-box approach is based on an associated metadata class (or buddy class) mechanism that we share with ASP.NET dynamic data. Some folks have called them “ugly buddies” and that name has caught on in terms of how the feature is described! The ugly buddies mechanism suffers from usability issues (eg. lots of repetition, and room for typos, or names getting out of sync) and discoverability issues. At the end of the day, it is no more than a workaround for the missing language feature that would enable adding metadata to members via a partial class.
Using the extensibility mechanisms in the bits today, we've published a sample that demonstrates specifying metadata in XML. In this post, I'll show you my first stab at providing a fluent-API-based metadata approach. I'd obviously love to see this in the product out-of-the-box, but it is another feature, and there is the realities of a product cycle. However, there is always a v-next. In the meantime, do provide feedback via comments - it will definitely feed into the design process.
[... continued here]
The ViewModel/MVVM pattern continues to gain popularity, with a blog post showing up every so often, and with tweets and retweets popping up even more often :-). At the same time, there are some interesting topics beyond the core pattern that continue to fuel experimentation. A big one amongst those is how should applications use dialogs when using the view model pattern.
The crux of the problem is the desire to keep the view model independent of UI concerns, and ensure it can be tested in a standalone manner, but that often comes to odds when you want the view model to launch a dialog, and/or do some work after the dialog is closed.
The most recent version of Silverlight.FX (v3.2) that I published earlier this week, addresses this scenario using a Task pattern. This blog post discusses that pattern, and opens it up for your thoughts.
The screenshot on the right represents my updated TaskList sample application (Click to run and create a task item, and double click on it to launch an edit dialog). All of the sample code is available along with Silverlight.FX for running on your end, and using the same pattern in your own applications of course.
Silverlight.FX provides a concrete notion of a view model representing a task with commit and cancel semantics in the form of a TaskViewModel base class. This serves as the base class for view models associated with dialogs. The view model associated with the main/parent window creates and initializes an instance of a TaskViewModel-derived class to represent the task as hand (when the view decides it needs to launch the dialog). The TaskViewModel raises completion notifications that can be used to do additional work in the parent view model. The main/parent window then creates a Form and assigns the resulting TaskViewModel as Form's view model, and finally shows the dialog. The user interacts with the dialog. The Form implements OK and Cancel commands that the OK/Cancel buttons invoke, and these commands are wired up to call into the TaskViewModel to commit it or cancel it.
I'll use some actual sample code to hopefully make this more concrete.
[... continued here]
These pictures are from a short couple day visit to Death Valley National Park earlier in the year (working through my photos back log).
There was an interesting mix of weather - no rain - but some cloudy and windy weather along with some sunbreaks, but the wind was powerful enough to kick up quite a bit of a sand storm, which was interesting to see, but an interesting challenge to try and photograph.
I think I managed to get a handful of good pictures of the sand dunes and the salt fields, including a 360 degree panorama.
Time for a brief but fun post... some time back Tim Heuer posted the Silverlight 3 bouncing plane gratuitous demo. Click an element, and the nearest corner would bounce backwards and forwards as it comes back to rest.
Tim had the code to setup the storyboards, and handle the mouse interaction in code-behind. I look at it, and immediately see a reusable component (even if it is a gratuitous one), or more specifically a behavior, that encapsulates all the logic, and can be attached declaratively in XAML to one or more elements simply without needing any code-behind logic. So I created one such behavior. I used this behavior in my TwitterBug sample at TechEd recently, and thought it could use a dedicated blog post. :-)
Here is a screenshot, which really doesn’t do much justice to something interactive. So go ahead, and click it to run the sample live. Click around on the images. And if you’re wondering how its done, go ahead and download the code. You’ll see a BouncingPlane class that derives from Behavior.

[... continued here]
In my last post, I described BLinq, or LINQ to Bing, an API that allows you use LINQ to access the Bing search results (ok, so perhaps BLinq was not the best of names, given prior art on that name ... but anyway). I also alluded to .NET RIA Services integration, which I'll cover in this installment. In fact, IQueryable and the LINQ pattern lie at the very heart of .NET RIA Services, in allowing developers to access data in a consistent manner not just on client or server but across client and server, and enabling code to compose queries naturally. If you haven't read the intro post, please take the few minutes to check out the LINQ snippets to get a general sense before continuing on.
You might use Bing in your rich internet application in one of two ways: have your client make requests to Bing by proxying through your server, or make requests directly from the client, using a cross-domain networking API, such as the one provided by Silverlight. I'll show both approaches in this post.
Here is a screenshot of the Silverlight application using .NET RIA Services. It is pretty straightforward and minimalistic. It has a search TextBox, and a couple of panels to display matching pages and images, along with some paging UI. Behind the scenes are a couple of DomainDataSource controls to perform the data loading one page at a time.

I have two apps with the same user interface demonstrating the two different approaches. The first uses RIA Services on both server and client. The second will use RIA Services only on the client, and will demonstrate how you can in fact use the client programming model and framework against a custom or very different back-end service (in this case, Bing).
[... continued here]
|