R – Interface Architecture for Silverlight App

So many options :-) Your choice probably depends on several factors:

• How much you want to reuse of the current solution
• Whether you want a full screen SL app, or just replace parts of the site with "richer" content
• How your current app is structured, both visually and what your ActionMethods are returning
• Timescales

RIA services might be a decent fit, as it would allow you to at least reuse your model and validation (if you're using data annotations) but it's some way off and likely to change before release.

The other option is a ground up Silverlight app, for which I'd recommend taking a look at PRISM and MVVM for structuring it (if only to keep the initial payload down!). You could probably reuse your model, and there is support for data annotations in Silverlight, but you wouldn't be far off recreating a new application.

The third option, and one that you may love or hate, would be to build "islands" of rich functionality in SL for areas of your site. You could use your existing MVC app and potentially have ActionMethods return JSON (or XML if you'd prefer) which your SL areas could consume and render. You'd have decent code re-use and you could enhance areas of the site in isolation.

An open ended answer to an open ended question :-)

EDIT: Judging by your responses, if it were me, I'd be creating a PRISM app. If it's currently a web app it should "sit" quite well with the region model (although you wouldn't be actually reusing any view code), and the dynamic XAP loading will help with your initial payload if you want a single full screen app. If it's a CRUD based app then you might want to take a look at the XAML Power Toys to quickly put data forms together.

Datawise you could either reuse your model and expose it via WCF or ADO.Net Data Services, wait for RIA services to stabilise (depending on your timescales) or still use the MVC action methods but return JSON from them for the SL app to consume.

WinRT is basically a collection of COM objects that wrap a bunch of Win32 API', exposed as CLI-compliant assemblies.

Microsoft modified their C++ compiler to consume and generate ECMA 335 (i.e. CLI) metadata rather than the more traditional and (largely) C++/COM-only MIDL or lib file formats. Microsoft also modified their "Chakra" Javascript engine to also consume and emit CLI metadata.

This means that when targeting WinRT, Javascript and C++ code, along with .NET languages, of course, can consume CLI-compliant (i.e. .NET) assemblies and can emit CLI-compatible (i.e. .NET) assemblies.

So, one can write WinRT code in C++, any .NET language (i.e. C#, VB.NET, F#, Iron*, etc) and in Javascript.

The WinRT API's will be VERY familiar to you if you've ever written any .NET code. The Windows team actually sought the help & guidance of the .NET Framework design team when designing WinRT, so the same design guidelines that have guided the entire .NET framework team and most of the .NET community for the last 11 years have been applied to the WinRT API's.

WinRT is, quite frankly, beautiful :)

WinRT's primary impact is that it replaces System.IO's file, network, stream IO classes with similar API's but which ONLY support async IO. This means that you will not be able to write apps that block threads while they wait for calls to the filesystem or external systems via the network to return unless you take explicit steps to do so.

This is a GOOD thing.

Luckily, the new async/await features of C# v5 & VB.NET v.next, along with specific support for C++ mean that you don't have to go and fundamentally change how you write code in this new async world - typically you just need to add an "async" keyword to method signatures that call async API's and then use the 'await' keyword prefixing each async API call.

I STRONGLY encourage you to watch Anders Hejlsberg's session which should make this whole thing very clear. While you're there, I also encourage you to watch several of the other //BUILD sessions, especially Harry Pierson's talk on using WinRT with C# & VB.NET and Mads' session on Async Made Simple in C# and VB.

I'd also recommend that you take a look at the improved Win8/WinRT platform architecture diagram that I blogged a few weeks back which should make things a little clearer.

As for .NET itself, as I articulate in my post above, .NET is not "going away". While a few of the .NET API's will be prohibited in WinRT apps (i.e. blocking IO API's), most of the API's you depend upon remain and are fully accessible.

Regarding Silverlight: Silverlight is a browser plug-in. It's a modified-subset of WPF and offers some very powerful and attractive features. So much so, in fact, that the Silverlight XAML engine was moved into the core Windows team and is used for most of the Metro UI rendering in Windows8 - even by the OS itself!

The net result is that most of your Silverlight code will run just fine with barely any modification, other than just changing a few 'using' namespaces.

There are a ton of XAML-focussed sessions from BUILD available to watch here.

With regards backward compatibility, aim to:

• Isolate code that you want to use in WinRT as well as in .NET desktop apps, Windows Phone, etc. into Portable Assemblies wherever possible.
• Abstract code that needs to take specific platform dependencies and consider manually loading them or using IoC to compose your modules together.

Frankly, I don't think it's Microsoft's job to write every framework for every scenario. There are several MVVP approaches/frameworks out there in the wild from various people with various pro's and con's. And if you don't find one then create one and stick it up on GITHub and become famous ;)

Above all, though, there's little stopping you from downloading and trying Win8 Consumer Preview & Dev11 Beta. Go get them and try them out - I think you'll find them very refreshing :)

HTH.

Update#1 in answer to the specific support for EF, WCF, etc:

You can find the WinRT API surface area enumerated here in some detail. The core WCF API's are enumerated here.

Note, however, that Microsoft is strongly recommending against using network coomms to communicate between Metro apps and other metro apps or desktop apps/services on the same machine. Read this SO question & Kate Gregory's answer - she links to a video where this scenario is discussed in detail.

If you want to communicate with off-box network services, then you have a wide variety of options including WCF, sockets, etc.

Regarding RIA: Microsoft are currently saying that if you want data, you'll need to get it via a service rather than directly from a DB. There's no ADO.NET for Metro and the recommendation is to surface data via OData, JSON, XML/HTTP, etc. Data as a service is very much a RIA scenario, so I expect RIA to be well supported for Metro apps. Here's a BUILD session on this very subject which may shed more light.

Only you can tell whether or not your specific scenarios are supported in WinRT. I think your best bet would be to download the bits and start exploring.

Update 2 following P&P's updated roadmap and guidance: P&P have recently published a new roadmap and guidance for building Windows RT / Windows 8 "store" / "modern" LOB apps.

This guidance includes updates to Prism/Kona and also includes EntLib6 & Unity3 (IoC). I encourage anyone interested in this space to study the published materials and reference apps - there is some great stuff in there :)