This depends on different scenarios. Below are some common approaches:
Pure Silverlight
One approach is to completely remove ASP.NET. This solution works best if you’re working on a new development. You only need to work on Silverlight, without any worry about integration problems. If you need to communicate with the server, you write Web Services, such as WCF. It will also help you when you need to port part or whole of your system to another hosting or even another platform, since the client and the server are completely separate.
Major ASP.NET, plus a Silverlight island
This approach is generally used when the Silverlight content and the ASP.NET content have little relationship. For example, an ASP.NET blog engine with a Silverlight media player in a blog post. This approach is very easy to implement, and allows you to reach the broadest audience. For example, if a user hasn’t installed Silverlight, he can still read the blog posts, but he can’t watch the videos.
Use ASP.NET AJAX instead of Silverlight
ASP.NET AJAX is designed to work with ASP.NET. It is mainly an extension to ASP.NET. While AJAX can’t provide you the advanced user experience that Silverlight can, for many scenarios, it should be sufficient. This approach also helps if you have strong ASP.NET experience, but are still quite new to Silverlight.
Within this approach, there are two branches. One is to mix the client and server code by using the UpdatePanel, AJAX Control Toolkit, and etc. The other method is to take the pure AJAX approach, where you write HTML and JavaScript instead of using server controls, and call Web Services to communicate with the server. The former branch is easier to implement, especially if you have strong ASP.NET experience but lack JavaScript knowledge. The latter branch proves to be better in an architecture when you want to port an AJAX application to other technologies such as Silverlight, especially since you only need to rewrite the client side code, and can keep the Web Services as they are. The programming model for the latter branch is similar to Silverlight. Therefore, this approach is rarely taken if you’re experienced in Silverlight.
Mix Silverlight with ASP.NET
More often, you may want to port an existing ASP.NET application to Silverlight, but you don’t want to completely rewrite the entire application. This is the most difficult approach since you’re mixing client side and server side technologies.
Before going with this approach, please consider if the above approaches can solve your problem. Ask yourself the following questions:
1. Do you really need a rich interactive user experience?
This is normally a requirement for consumer oriented applications, but for most business applications, you only need a “good” user experience, which AJAX is sufficient to provide.
2. Can you add Silverlight islands to your existing ASP.NET application instead of mixing the contents?
This should work for most scenarios. For example, Windows Live Mail is built in ASP.NET, with a few Silverlight islands, such as a slideshow program that allows you to view photo attachments with enhanced experience (actually, most Microsoft created web applications take this approach).
3. Will this be a good chance to revise your architecture?
Most traditional ASP.NET applications use the B/S or three tire architecture in which the application works with a database either directly or through a business logic layer. When porting applications to other platforms, these architectures will introduce many problems. When investigating Silverlight, it is also a good chance to adopt SOA. Add a service facade layer on top of the business logic layer, and you can work with the services from almost any client, such as an ASP.NET application and a Silverlight application. If you are already on SOA, it should be trivial to port to Silverlight, since you only need to rewrite a client application. With SOA, the ASP.NET AJAX approach and the Silverlight island approach will also be much easier to implement.
If none of the above approaches is suitable, you may have to mix Silverlight content with ASP.NET. When using this approach, keep in mind that Silverlight can’t call ASP.NET server-side event handlers, and each post back (either partial or complete) will cause the Silverlight application to reload.
