I have the task to migrate a large silverlight business application in a new living technology. I had choosed asp.net MVC and web api.

As we know, silverlight uses MVVM design pattern whereas asp.net mvc is obviously using MVC pattern.It looks like migrating silverlight logic to mvc wouldn't be easy at all.

As I know in MVC you can't manipulate the data you get in the client because you simply get HTML. I've never used MVC so I don't know the differences.

a.Can I achieve similar logic in MVC? b.Are there any other frameworks needed? c.XAML binding and data manipulation from svlight, in mvc, is done from the code behind?

Are there any other suggestions?

  • Actually with the default ASP.NET MVC template you get .cshtml files for the views so you can use C# in the views. Though I personally can't stand backend code in the view so I tend to only use .html for mine.
    – Alternatex
    Feb 29 '16 at 8:03

Your basic problem is that the client technologies are fundamentally different - one of the key drivers for the evolution of Silverlight was to put "rich" client capabilities into the browser.

What this means in practical terms is that the interactive nature of a rich client app is not available in a simple MVC app given that (notionally at least) you're serving relatively static pages.

However one of the reasons for the demise of Silverlight is that you can now build rich client applications in the browser using JavaScript and MVVM patterns / frameworks. So your application would then be a JavaScript (or better TypeScript if you're a C# developer) front end SPA (single page application) talking to a Web API back end.

There are a scary number of choices for building the front end (Aurelia, Angular, Ember and many others that encompass some or all of the layers needed to do MVVM in the browser).

You're still going to need to work out what logic belongs on the server (whether any that was in the Silverlight client should be moved) and what now needs to be re-written.


Bear in mind also that "single page" doesn't necessarily mean everything has to be in a one single page/app rather - if there are logical separations you can build smaller, less complex pieces that encapsulate one set of functionality.


We faced a smimilar problem with our client - while raw MVC.NET is a good tool, it is considerably different from our old silverlight client - especially worrisome was that most of our developers are not really familiar with Javascript, inviting poor performance and compatibillity problems. In the end, we decided to go with a rather "dumb" client, compared to Silverlight, where most decisions are made on the server and then communicated through an JSON-rest-api.

The client itself is a thin-client, designed to display the data - manipulations are send to the server and evaluated there. The technology is based on typescript, angular js, d3 and chuzpah for tests. Our developers like the plattform - but there is a lot of framework code we had to write, and the learning curve was .... unpleasant.

What worked well for us was to hire two "web guys" which stimulated the rest of the team, also we have a very good architect, who has helped to pull through more complicated problems.


I've also been researching on methods to upgrade my company's lightswitch app. Apparently, you can merge MVC and lightswitch but it must be lightswitch 2013 or higher. I haven't tried this solution yet, since I'm looking to completely convert to MVC. Even after the inclusion of MVC, there doesn't seem to be any easy way to do a full conversion without doing quite a bit of extra work to create models, controllers and views again. Good luck.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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