We’ve built our data model. We’ve added some business logic. We’ve added authentication and even done some personalization to our application. Now that the fundamental portions of the application have come together so nicely, let’s discuss the runtime experience and how we can troubleshoot, debug, and understand what’s happening when users run our application.
The editable grid in LightSwitch supports a number of scenarios automatically that you would implement manually in most other development environments. If you find that it doesn’t meet your needs, you can of course leverage custom Silverlight controls from third-party vendors, but let’s focus on what we get out of the box.
Simply click on a column header to sort the grid by that column. You’ll see an arrow appear on the column header indicating the column that is sorted and the sort order. Click that column again to toggle between ascending and descending sorts.
From an end user perspective, if you are running the app as a desktop application, you can export the current contexts of any grid to Excel (Figure 9-1). Due to the Silverlight security sandbox restrictions, this functionality is not available when running as a web application. There are other options to consider if you need to run as a web application. In addition to third-party extensions, many folks will embed a link to a Reporting Services report or generate and output a CSV file with their own code. If running as a desktop application works for your scenario, that’s the easiest approach.
Need to find a specific record? Enter some text into the search box and all fields that are tagged as searchable on the entity will automatically be searched. What makes this particularly interesting is that we are not just searching the data displayed in the current page on the screen. When a user enters a keyword to search for, that query is sent as a parameter back to our web services and processed into a query against the database.
In this section, we will use a freeware tool called Fiddler. Fiddler is a web debugging proxy that logs HTTP traffic between your computer and the Internet. If you run a web debugging proxy and watch the traffic between your browser and the services that form the server side of your application, you will see a number of Representational State Transfer (REST) service calls being made by your generated Silverlight application. You will see paging parameters, sort parameters, and searches all appended into the query that is run on the server side.
This is important because it means that you are not transferring thousands or millions of records from the database to the application server or even to the client. Rather, the services are taking the parameters from your user interface, passing them to do server-side paging, and generating appropriate queries in the entity framework layer to minimize the size of the data sent over the wire.
As an example, inspect this OData REST query made when searching for the word “Write” on our ticket page. Notice that this is a query against the Tickets entity and that we check each of the searchable properties to see if they contain the word “Write.” By implementing the IQueryable interface on the generated services, the user interface is able to dynamically generate these queries without you manually creating each possible query at design time.
http://localhost.:51218/ApplicationData.svc/Tickets()?$skip=0&$top=45& $expand=Queue,Requestor,Assigned&$inlinecount=allpages&_search=write
If you want to watch the traffic between SilverLight and your services when debugging on your local box, you can launch Fiddler, start debugging your application, and find that Fiddler is not seeing the traffic between your browser and the debug version of your application. This is because traffic to the local host is excluded by default when using a web debugging proxy. You can modify the configuration and there are many blogs that will show you how to do this, but there is also a much easier workaround. The solution is to request the application from “http://localhost.” instead of from http://localhost. By adding a period after the localhost server and before any port number or directory, path requests will still route correctly to your applications and the traffic will be correctly captured by your web debugger. To do this, we’ll want to configure our application to run as a web application so we have access to the URL in Internet Explorer.
Note
In LightSwitch 2012, communication between the Silverlight application and the server is accomplished by using WCF Data Services supporting the Open Data Protocol (OData). This allows them to be queried from any platform including Microsoft Excel and PowerPivot.
Microsoft has described LightSwitch as “The simplest way to create business applications for the desktop and for the cloud.” Traditionally, one would start with different project types and use different libraries and APIs when writing Windows Forms, web forms, or Azure-deployed applications. With LightSwitch, this isn’t a decision that needs to be made up front. LightSwitch design tools help you create the logical model of your application and Visual Studio generates the code.
Changing the application type is simple. Double-click on the application properties in the Solution Explorer, choose the Application Type tab, and select the Web radio button (see Figure 9-2).
Once we choose to create a web application and hit publish, we’re guided through a wizard to choose the type of application server that our application will use. In this case, select the one that hosts services on IIS.
When running as a desktop client, you can have a self-contained application where all services run on the end user’s machine. This is not recommended for most scenarios, as each user will be connecting to the database from their machine without connection pooling, thus limiting the scalability of the application.
The more common scenarios involve hosting the application server on either an IIS Server that is accessible to your clients or hosting the services via Windows Azure. For this book, we’re going to leverage hosting on an IIS Server for a more traditional on-premises deployment.
After selecting these properties, launch your application by choosing debug from the Debug menu or just clicking the green start button on the toolbar. Internet Explorer will open and your Silverlight application will load. Just modify the URL by adding the period after localhost and before the port number, as shown in Figure 9-3.
If you are running Fiddler or another web debugging proxy, you’ll see that the traffic between your browser and the services is now captured. You’re seeing the requests for information about Tickets and People and the call to the GetPersonByAccountName query where the details of our logged-in user are fetched (Figure 9-4).
In addition to giving us the ability to use a web debugger when developing our application, running as a web application will allow us to integrate our application into SharePoint later by embedding the URL of our application as an iframe or a Page Viewer Web Part within SharePoint.
In this chapter, we learned about running our LightSwitch application as a Windows application or as a browser-based application. We discussed using a web debugger such as Fiddler to monitor traffic between the client and the server and we learned about how searching, filtering, and sorting requests are added to the query string of our REST service call. In the next chapter, we will discuss using LightSwitch with SharePoint data by adding a knowledge base to our SharePoint side, which will be populated by our LightSwitch application.