I think I have a grasp on the expectations of consumer application development for Windows 8. Create a new Metro-based UI on top of WinRT, deploy it to your customer via the Marketplace, and everyone wins. Seems simple enough. Unfortunately, I'm not in that business.

I work on internal, line-of-business applications for a large enterprise. We currently use .NET technologies such as WPF and Silverlight in order to create rich UIs that can be easily deployed to our users via the web or ClickOnce. The applications can support WinXP and Win7 without too much headache, and our developers get to use XAML which is a very solid UI technology.

It seems like WPF and Silverlight have questionable futures at this point, so it is a bit worrisome to continue investing in those. But a Metro UI doesn't seem appropriate for enterprise applications, and the WinRT API is quite limiting with regards to "typical" things that enterprise applications need to do.

How should I be architecting my XAML-based applications, currently being deployed to WinXP and Win7, so that they will be supportable and evolvable on Win8?

Assume for the purposes of this question that the features provided by HTML5 on top of ASP.NET are not adequate for the applications I'm looking to create. I understand that I can use HTML5 for some applications, but I'm trying to figure out what I should do when that isn't enough.

Edit #1: This is in response to @Emmad Kareem's comment. I do agree that Silverlight/WPF are viable in the short term (2-5 years). However, the applications we produce have potentially very long lifetimes (10-20+ years). So survivability in the long term for a given technology is a concern for us. Also, we have some concern that it will be more and more difficult to find developers that are interested in Silverlight / WPF development if those technologies are considered "dead" by the community. I just want to understand my options and make a decision with my eyes open.

  • Have to run to a meeting but I've got an answer for you :) Commented Dec 19, 2011 at 14:01
  • 2
    Why would you change the WPF/Silverlight you are already familiar with? Your statement "WPF and Silverlight have questionable futures", well, Microsoft will not drop this technology over night. Whether it will keep growing is not a real concern if you have enough functionality with it today. In short, you must have a solid technical reason for considering a totally new architecture. Some of the scare out there is from people loosing their experience to yet another technology. I can't blame them.
    – NoChance
    Commented Dec 19, 2011 at 14:01
  • 3
    You want a single technology stack to last 10+ years? Why not focus on good architecture and design principles to let your system evolve over time to use the technologies that are appropriate? Take a look at Visual Studio - it's been around since 1995 and has evolved over time. For example, Visual Studio 2010 added a major UI refresh that included the use of WPF and other architectural changes to add extensibility points. You can't control what technologies or paradigms are going to be big next year, much less in the timeframe you are looking at.
    – Thomas Owens
    Commented Dec 19, 2011 at 14:14
  • 5
    What makes you think you will be running Windows in 20 years?
    – JonnyBoats
    Commented Dec 19, 2011 at 14:22
  • 1
    @JonnyBoats : Because we were running it 20 years ago? Or because their main competitor is based on a system even older? There is no way to predict the downfall or the survival of a specific technology.
    – Matthieu
    Commented Dec 19, 2011 at 14:34

4 Answers 4


How I Learned to Stop Worrying and Love the MS-Stack

You can still run VB6 apps on windows 8. Retro-compatibility for good or bad has always been a trend in the MS ecosystem. You shouldn't worry about the survival of technologies like WPF / Silveright, and even winforms for that matter.

On the other hand, you have to accept that for a long term project, you will never have the latest, cutiest technology.

In fact the questions you should ask yourself about the choice of a technology are :

  • Is my team comfortable enough with that technology to be productive?
  • Is my team happy to use that technology?
  • Can I recruit people for that technology?

That's the combination of the answers to this questions that should lead your choice, and not the trends forged mainly for marketing reasons.

For more about this thematic of ever-changing technology, you should read "Fire And Motion" By Joel Spolsky :

The companies who stumble are the ones who spend too much time reading tea leaves to figure out the future direction of Microsoft. People get worried about .NET and decide to rewrite their whole architecture for .NET because they think they have to. Microsoft is shooting at you, and it's just cover fire so that they can move forward and you can't, because this is how the game is played, Bubby. Are you going to support Hailstorm? SOAP? RDF? Are you supporting it because your customers need it, or because someone is firing at you and you feel like you have to respond? The sales teams of the big companies understand cover fire.

And that was written nearly ten years ago.

Architecture and Technologies

Architecture and Technologies are two separate things and choices to do :

You can use services, resources, third party controls, ORMs, etc. with all this technologies, and maybe, or maybe not, with the next ones.

You can twist and bend MVC in many ways with all those technologies : Binding or not ? code behind view or not ? Controller or not ? ViewModel everytime or only when needed ? There are so many ways to implement a design pattern, even within the scope of one specific technology.

That would be irrealistic to force you into one of them without advanced knowledge of your project and team. It would only be based on personal preferences, and would end-up in a "my technology is better than yours" showdown.

The only thing that can be honestly and objectively suggested is to use the best practices you can apply to create an architecture that will stand the test of time, and maybe, really maybe will be portable or reused at least in parts with a future unknown technology. And that upgradability/portability shouldn't even be the main purpose of your architecture.

The main purpose of your architecture and choosed technology is to deliver a product to your boss/customer that meets his realistic requirements.

MVC (and it's younger brother MVVM) proved more and more to be a basis for robust architecture since 1979 in the OOP languages arena and beyond. But choosing what specific technology should be used in a 10 years long project should remain your decision.

  • I totally agree with this answer. You can never know for sure. But there are multiple technologies that could satisfy the questions you lay out, and I still have to choose among them. Commented Dec 19, 2011 at 17:38
  • @jkohlhepp : added a paragraph about architecture and technologies. I stand my point that it's impossible to objectively recommend one technology over the other or one architecture over the other.
    – Matthieu
    Commented Dec 19, 2011 at 18:44
  • Your stance is that there is no objective basis for comparing architectures / technologies? Isn't that the whole purpose of the architecture discipline? I agree that it is all about my bosses requirements. One of those requirements is maximum longevity for cheapest cost, hence this question. Commented Dec 19, 2011 at 20:10
  • @jkohlhepp : IMHO software architecture discipline is like medicine. You get experience in finding the right treatment for a specific disease. There are different ways to do so sometime, and it might be dangerous to try to heal everyone the same way with the same treatment. If you have an effective team of experienced programmers in WPF and Silverlight, then stick with it, and keep your existing architecture. If you have to change it, don't change it only because there are new ways to do things, that your are already doing efficiently, marketed by Microsoft.
    – Matthieu
    Commented Dec 19, 2011 at 20:29
  • I can get on board with that Matthieu. Thanks for the thoughtful responses. Commented Dec 19, 2011 at 20:32

One thing I will address in my book on MVVM is how to leverage the pattern to create a reusable core application. You should be creating a native UI for the various platforms you target (be it web, silverlight, phone, WPF, or WinRT). But for the most part, you can encapsulate the logic driving that UI behind a ViewModel.

Any services you access should be wrapped behind an interface (Facade pattern) that is more or less portable between platforms. The interface should map to your client API on the front and translate to the API of the wrapped service on the back.

This strategy helps you create a solid core framework that only requires a new UI to be layered on top of it. Think of it as your View Model being the muscles, your services make the skeleton (and organs). WPF/Silverlight/WinRT form the skin.

In fact, one thing that I point out very early in my book is that MVVM isn't as new as it seems to be. Dolphin Smalltalk had a similar pattern that they called MMVC (the two M's were Application Model and Domain Model). The ViewModel we use today is just a combination of the Application Model and Controller from MMVC. In fact many developers are finding that sometimes separating the ViewModel into it's two components makes sense (the controller being used for navigation and orchestrating multiple VMs so that the VM can remain blissfully unaware of other components).

  • I totally agree about layering out different pieces of the application. And I also totally agree that you should make your UI as dumb as possible because UI technologies tend to churn quite a bit. But, even after creating those layers, you still have a guess to make on which technologies will be better / cheaper in the long run. Commented Dec 19, 2011 at 17:36
  • If I had to guess...while HTML5 is the new rage these days, Microsoft is going to continue to support XAML because they control it. They learned their lesson from Java (they were originally planning to use Java as the premier .NET language when Sun went all litigious on them) the HTML support is for reach. Building your app on solid principles (Declarative UI backed by a rich portable object model) should help you weather the storm. I even have examples of doing MVVM in Javascript (check out knockout js). Commented Dec 19, 2011 at 18:34

You say XAML is solid but then say WPF has a questionable future. Unless I'm missing something, WPF uses XAML and I don't see the two ever being separated. Is there some news I'm missing about WPF possibly using some other base technology, or about Microsoft even possibly considering of building yet a another new way to build UIs? Outside of that, I doubt WPF is going anywhere, but it wouldn't be the first time MS has obsoleted boatloads of our code...

If you need a rich UI app and HTML5 won't cut it, and you're org is committed to windows OS, I think WPF is the best choice as it's the lastest/greatest right now, certainly over winforms...

  • The direction I've heard from MS has hinted that WPF doesn't have much of a long term future. But they haven't announced anything. I expect they will put it into a "maintenance mode" like they did with LINQ To SQL. Commented Dec 19, 2011 at 17:35
  • WPF is depracated in Windows 8 (in that you get abruptly dumped back to the "desktop mode" and out of the immersive Metro experience). However, you can build Metro apps with XAML. They are completely separate technologies.
    – Domenic
    Commented Dec 20, 2011 at 1:55
  • Erm, no its not deprecated in that the desktop is still a key part of the experience. As for "completely separate technologies" - really? Surely much closer to variations on a theme as is already the case with WPF vs Silverlight (as opposed to, say, the use of XAML for workflow...)
    – Murph
    Commented Dec 20, 2011 at 11:32

My take on this is that you should not focus too much on the implementation details of your applications. If you look at a bigger picture, you can isolate your technology dependencies. By isolatin the dependency on e.g. xaml/wpf/silverlight you ensure that you can replace the ui component/technology with a next generation technology and therefore guarantee continuity even in 20 years time. This will also help decoupling your systems components and therby the impact of having to perform such a replacement. (In this I make an assumption that for providing continuity it's okay to tinker with a solution to get it going on a next generation platform)

An other way of providing isolation from these technology dependencies is enabling virtualization. If you craft your applications in such a manner that you are able to run them in a vm, you will be able to do so in 20 years time!

  • From a certain sense I can understand this perspective. However, I do need to choose a UI technology at some point, and depending on that choice it will require replacement / updating sooner or later. I'd like to make a choice that results in maximum longevity. Commented Dec 19, 2011 at 20:07
  • According to the lifecycle site Silverlight5 will be supported until October 2021 support.microsoft.com/lifecycle/?p1=16278 So whatever happens to the roadmap, it's still a solid choice.
    – Carlo Kuip
    Commented Dec 19, 2011 at 20:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.