Today’s Task:

Add some Silverlight content to an existing Asp.Net MVC project. The MVC project contains the standard CRUD for the application, while the Silverlight is meant to provide rich visualization of the data.

Prerequisites:

• VS 2010
• An existing Asp.Net MVC 2.0 project
• Expression Blend 4.0 (installs Silverlight 4 and Silverlight 4 SDK)
• Silverlight 4.0 tools for Visual Studio 2010

Creating the Project:

As stated in the opening and prerequisites, I am starting with an existing Asp.Net MVC application. You should have Blend 4 installed, and have also installed the Silverlight 4 tools for Visual Studio.

1) Right click on your web project and choose add new item (ctrl+shift+a). From the add new Item window, click on Silverlight under Installed Templates and then select the Silverlight Application. Name your Silverlight application appropriately. In my example, I have named my project DataVisualization. Click Add

2) The next screen that comes up is the “Add Silverlight Application” screen. I accepted the defaults with the follow exception, I changed the location from being a sub folder of my MVC application to one level higher. The destination folder, ClientBin is still created in your MVC application. Make sure that you select Silverlight 4 for the version. Finally click Add.

3) You should now have the following in your solution.

• Your existing Asp.Net MVC application
• A new Silverlight 4 application named DataVisualization
• A DataVisualizationTestPage.aspx in your MVC application
• A DataVisualizationTestPage.html in your MVC application
• A Silverlight.js in your MVC application

We will eventually remove the test pages, but for now we will leave them so that they can serve their intended purpose.

4) Build the solution. You should see a DataVisualization.xap added to the ClientBin folder in your MVC application.

5) Right click on DataVisualization.html and choose view in browser. You should see an empty page in the browser, but get no errors. Right clicking anywhere in the browser window should bring up the Silverlight context menu.

Integrate the Silverlight Application

In this stage, we are going to make our new Silverlight application appear like it’s part of the rest of our MVC application. Right now if you browse to it, it doesn’t look like its part of anything. We also want to be able to allow our users to navigate thru our web application so we need our existing menu to show up.

1) Either create a new controller/view or re-use an existing controller/view in your MVC application to house your Silverlight application. I’m going to reuse an existing controller called Dashboard, which has one view, Index.

2) Open up your view, and the DataVisualizationTestPage.aspx file. We need to move some stuff over to our view so it displays our Silverlight application. I have some pre existing styling and layout defined, so my view is going to look differently from yours. I also store my java script files in a specific location, so I will be moving the included silverlight.js as well. The screen shot below shows what I am starting with in the view for reference.

3) If you don’t have any existing standard for your JavaScript, you can place the two script tags from the test page somewhere before the reference to the Silverlight object. For example, place the two script tags just below the second content place holder. Next, copy the form tag inclusive and paste it into your view. For me, I pasted it into my div tag that I have setup to control my formatting. In the screen shots below you can see my view, and resulting web page. We still have an empty Silverlight control, but now it looks like its actually part of our website.

4) Remove the DataVisualizationTest.aspx page, but keep the HTML page as we will need it in the next section.

Working with Blend

The final step is to begin adding content to our Silverlight application. For this we are going to switch to Blend to make sure that we are able to work in both tools.

1) Start up Blend and choose to open an existing project. Browse to the location of your DataVisualization project (folder that contains DataVisualization.csproj) and open it. You should see the content of your project listed on the left under the project tab (assuming default Blend layout) and the empty MainPage.xaml in the middle. Notice that we have a solution called DataVisualization, and that I did not open up my existing MVC application solution.

2) Go to Project in the tool bar, and click Run Project (or press F5). You will see that our empty MainPage is shown using the DataVisualizationTest.html page, and that we are using the local Asp.Net development server. This is good enough for me. I’m hoping that with this setup I can work independently of my MVC application, and more importantly, a designer would be able to work independently as well. When deploying my application to production, I can remove the DataVisualizationTest.html page.

3) TFS Integration – At this point I can’t figure out how to get Blend to work with TFS. It’s possible since I downloaded the trial version that it does not include TFS support, or I need to install Team Explorer on top of Blend. For now I can use the Explorer add-in to get by.

Conclusion

At this point we have a functioning Silverlight application, integrated with an existing Asp.Net MVC application. We are able to work independently of the web application in Blend and vice-versa. This is my first attempt at this type of solution, so I will post a follow-up in the future to report back how well it worked, and if I needed to make any changes.

This post is part of my PDC09 Conference Notes series. These are my raw notes taken while watching the various session videos from PDC09. Refer to my original post for some conventions I tried to use.

PDC Session Link: Networking and Web Services in Silverlight

This session went over the different ways to expose data to a Silverlight application. Data access requirements for Silverlight was grouped in two ways and presented as the following graphic:

Each example fell somewhere on the X/Y axis of the chart above. Resource Centric was explained to be CRUD operations, while operation centric was more behavior driven.

Forms Over Data

The first examples were your typical forms over data applications, which are Resource Centric and follow a Request/Reply model.

If you control, and have direct access to the data, then RIA services was recommended. Aside from a short demo, not a lot of time was spent on RIA services, as there are other presentations that get into the details.

Another option for when you control the data, is to use WCF Data Services, which exposes your data in a RESTFul manner that adheres to the open data protocol (OData). In addition to data you control, services like SharePoint expose the data contained with-in via the open data protocol as well. The advantages to using OData sources over public REST services, is that more is known about the data, so you get a better development experience.

If you are working with a public data store exposed with REST, and it’s not OData, then use the enhanced (for Silverlight 4) ClientHttp library. It has a good programming model, and a lot of the deficiencies in previous versions have been solved. For example there is now support for Basic HTTP Authentication secured with SSL.

2 Way and Streaming

The second group of examples looked at duplex and streaming scenarios. The first example was a chat application which is an operation centric example that has some request/reply elements, but mainly users a duplex model. WCF was the recommend technology to support the duplex model. The included binary encoder provided a 71% performance improvement over the standard text encoder, even over HTTP. Binary has been the default encoder since Silverlight 3, but is only useful when both endpoints are .Net applications.

Duplex itself can be setup in your WCF bindings in one of two ways. For internet scenarios, you will need to use an HTTP binding, which is a polling based duplex model. While not present in the beta that was released at PDC, there are plans to enable HTTP Chunking, which would allow for multiple messages per HTTP request to increase performance. For intranet scenarios, you can use the NetTcp binding for the best performance. Remember, since this is WCF, you code once, and just change your bindings as needed.

Silverlight 4 supports UDP multicast, but it is pretty much an intranet only solution, as your network must be configured to support UDP multicast.

There is a new Silverlight TCP Socket Policy server project template in the online template gallery (accessible in VS 2010). This makes it very easy to setup the policy server to allow cross domain socket calls for your Silverlight application. An enhancement being considered for Silverlight 4 is that if the application has been elevated, then you will not need to worry about policies.

This post is part of my PDC09 Conference Notes series. These are my raw notes taken while watching the various session videos from PDC09. Refer to my original post for some conventions I tried to use.

PDC Link: Advanced Topics for Building Large-Scale Applications with Microsoft Silverlight
Presenter: John Papa (@john_papa)

The title of this presentation is a little misleading. It could have just as easily been titled, best practices for building line of business applications in SilverLight. The concepts, if not most of the code can be applied to WPF as well. There was a lot of talk about Prism, which I have not looked at in great detail. However, as a result of this presentation, I will take a closer look at it once I get around to working with SilverLight and WPF more. John pointed out several times that you are able to pick and choose what parts of Prism you want to use, which at least makes it sound a little less invasive then some of the other things to come out of Patterns and Practice.

A similar framework which is not developed by Microsoft is Caliburn. Which one is better, is probably open to debate, and both are continued to be developed. John did mention some gaps in Prism, which he developed some code for (posted via his blog), but perhaps these are available in Caliburn. If you are just starting out with SilverLight or WPF, I would suggest looking at both frameworks. If you are already using one or the other, I don’t know how much sense it would make to switch, but I always like to keep my options open.

MVVM

The first part of the presentation was focused on defining MVVM, or the Model, View, View-Model pattern. The primary benefit of the MVVM pattern, is that is allows for good separation of concerns, which leads to increased testability and maintainability. As you can see below, a lot of time was spent on describing the View-Model and how it fits in, while the View and Model are fairly straight forward.

• View: Responsible for rendering the UI only
• Model: Contains your domain entities (i.e. customer, order and order details)
• View-Model:
  • Handles the communication between your View and Model thru bindings, commands, events.
  • Responsible for providing everything (data) a particular view requires.
  • Sometimes your View-Model will look almost identical to your model. Other times, it will contain a mash-up of various entities as required by the view.
  • Ensures that your view knows nothing about your model, and that your model doesn’t known anything about the view (or require references to view related dependencies)

Three ways to implement MVVM were presented. I had never considered the first two, while the 3rd one is where frameworks like Prism, Caliburn, Ninject (Inversion of control) come into play.

• ViewFirst (Static Resource): View Model can be created as a static resource in the view. This tightly couples the View Model to the view, but gives you the best experience when using Blend (referred to as blenability)
• ViewFirst (Code Behind): The view is injected to the View Model constructor. Since you loose the blendability, I’m not sure why you would pick this over option 3.
• View + View Model Marrige: Use a intermediary to marry the View and the View-Model together. Again, you loose blendability, but this is the approach that everyone takes when using Prism, Caliburn or a home grown framework.

When creating a SilverLight application using MVVM, there are some common functionality that you need to implement, which is where Prism and Caliburn come into play. Since this session used Prism, I will list what was shown, which was limited to what Prism can offer. I expect that Caliburn offers a similar set of functionality.

• Shell: Container for all UI modules, such as menus, windows etc.
• Regions: Shell is made up of regions which control where UI modules are displayed.
• Modules: Separate code modules that can be developed in isolation and then loaded by Prism. Modules can talk to one another thru event aggregation (I wonder if MEF would be a better choice)
• Event Aggregation: An eventing model that allows for cross module communication.
• Commands: SilverLight 4 adds support for commands, so it is my understanding you do not need to use Prism’s command support anymore.
• Bootstrapper: Controls application startup and configuration. Configure your IoC here.
• Delegate Command object for use with commands (very simple class to create if you are not using Prism)

Commands:

• Invoke an event on your view and have your view model respond to it.
• When you invoke a command, you expect a response.
• Commands work out of the box well with buttons. However you need to create new command objects that implement ICommand for use with other controls. John puts these objects in his Infrastructure dll, and I think he may have provided some of this code on his blog.
• I still have a lot to learn on commanding