In the past decade, a lot of web applications were written in ASP.NET Web Forms. It is no doubt that many developers want to port those applications to Windows Store app. This article provides some guidelines and a sample solution to simplify the migration process.
The sample ASP.NET Web Forms application is a typical news publishing application. It contains the following pages:
Most ASP.NET Web Forms applications are server centric. A user types a URL in the browser, or submits a form. The browser issues a GET/POST request to the server. The server handles the request, invokes business logic, generates a static HTML file, and sends back the client browser. Finally, the browser renders the HTML file.
On the other hand, a Windows Store app uses a client centric model. The application is installed on the user machine. When the app starts, it does not request the server. If an app wishes to communicate with a server, it has to issue HTTP requests manually. The browser will not handle requests automatically. Actually many Windows Store apps do not have a browser.
For developers with knowledge and experience in ASP.NET Web Forms, he/she probably has to rewrite the presentation layer from scratch, and add a service layer for communication between client and server. However, most of business logic and data access module are reusable.
Developers can port the server side to ASP.NET Web API, which is a new feature in the latest version of ASP.NET, and thus provides a natural migration path.
In general, the migration steps can be summarized as follows.
ASP.NET Web Forms provide a lot of server controls. Some of them simply wrap standard HTML controls, while others offer a lot more. For example, ListView and GridView allow developers to display/edit complex data model.
To port the presentation layer to Windows Store apps, server controls must be ported to HTML client controls. Porting standard controls usually doesn’t take too much effort. For example, asp:Button can be ported to button, and only a few properties need to be changed.
<asp:Button ID=”button1” runat=”server” Text=”Click” />
Certain complex server controls can also be ported to client without too much effort, thanks to new additions to HTML5. HTML5 provides a lot of new controls, such as range (slider), date, and so on.
In ASP.NET Web Forms, a typical approach to display data is binding server controls to data sources. In a well-designed application, ObjectDataSource is used to provide the data, as it allows developers to separate presentation from data access. In simple scenarios, sometimes UI is directly bound to data. For example, LinqDataSource and SqlDataSource can be used.
In Windows Store apps, the client application does not have access to a database, even if the database is installed on the local machine. All data must be provided from files in local storage or cloud services.
If ObjectDataSource is used in the Web Forms application, the same architecture can be used in Windows 8. A data source is provided, where the data may come from any place such as a cloud service. The UI binds to the local data model. WinJS.Binding.List can be considered as the counter part of ObjectDataSource. If the Web Forms application uses other data sources, developers need to customize it. For more information about data binding, please refer to http://msdn.microsoft.com/en-us/library/windows/apps/hh758311.aspx.
Example: Bind a data source to a ListView
<!-- Template -->
<div class="commenttemplate" data-win-control="WinJS.Binding.Template">
<span data-win-bind="textContent: User.UserName"></span>
<span>posted at: </span>
<span data-win-bind="textContent: PublishTime"></span>
<div data-win-bind="textContent: Content"></div>
<div id="commentsList" data-win-control="WinJS.UI.ListView"></div>
// Configure the data source.
var commentsList = document.getElementById("commentsList");
var listView = commentsList.winControl;
listView.itemDataSource = getDataSource();
listView.layout = WinJS.UI.ListLayout;
listView.itemTemplate = document.getElementsByClassName("commenttemplate");
If the data comes from a cloud service, the client and cloud service communicate each other. In addition, ASP.NET Web Forms server control event handlers run on the server side, but the event handlers in Windows Store apps run on the client side. To communicate with server-side business logic, a service layer should be added.
A service layer is useful not only in building a Windows Store app, but also in supporting additional rich clients in the future. The same service can be consumed in almost any devices, such as Windows Phone, iPhone, and Android.
Traditionally, SOAP services (such as services built with ASP.NET Web Services or Windows Communication Foundation) are used to build service oriented solutions. However, most modern services (in particular consumer oriented services) are built as REST services. REST uses standard HTTP protocol. It doesn’t force a strict request/response format as SOAP does. So it is more agile, and is supported on any platform that supports HTTP protocol. On the other hand, many platforms do not offer out-of-box support for SOAP.
To add a service layer on top of an existing ASP.NET application, here is the good choice ASP.NET Web API. The best of it is ASP.NET Web API is part of ASP.NET, and thus a lot of existing skills can be used.
To consume a RESTful service from a Windows Store app, standard XMLHttpRequest can be used. Third party libraries, such as jQuery’s ajax function, also works. In addition, WinJS provides an xhr function, which simplifies the programming model. It supports promise style programming, which simplifies making asynchronous web requests. For more information, please refer to http://msdn.microsoft.com/en-us/library/windows/apps/hh868282.aspx.
Windows Store apps are not limited to normal web apps. They provide a lot of unique and rich user experience. Below is the common feature list which could be integrated into normal web apps.
Many Web Forms application use ASP.NET membership to implement authentication and roles to implement authorization. This is great if the application only needs to support browser clients. Browser clients can essentially delegate all authentication/authorization to server. A cookie can be used to store a token, which is validated on the server when the request is made.
On the other hand, non-browser applications do not have cookie built-in. To make the sign in process more secure, a client application should not get user’s credential directly. A typical practice is to embed a web browser in the client application. The browser handles authentication, notifies the host app when the user is authenticated, sends the host app a token, and the host app can then use the token to communicate with the service in future requests without asking the user to sign in again.
Windows Store apps (or more precisely, WinRT environment) offer a system component to simplify the process. Developers can use WebAuthenticationBroker to sign in to any services compatible with OAuth standard. Using WebAuthenticationBroker, developers need not to worry about how to interact with a web browser control. What’s more, WebAuthenticationBroker simplifies SSO (single sign on). For more information, please refer to http://msdn.microsoft.com/en-us/library/windows/apps/hh465281.aspx.
On the server side, the authentication logic also needs to be modified. The new project templates in ASP.NET MVC 4 help developers generate web applications that support common online identity providers (such as Windows Live ID and Facebook) with only a few lines of code. Under the hook, an open source product DotNetOpenAuth is used. Developers can port the MVC project templates to ASP.NET Web API with some additional efforts.
The ASP.NET Web Forms application mentioned earlier has been ported to a Windows Store app. The migrating process follows the above steps.
The resulting app contains following pages. The feature set is almost identical to ASP.NET, but the UI is somewhat different.
In addition to the pages, several new features are implemented:
A new service layer is introduced on the server side. It is implemented in ASP.NET Web API. Most existing business logic and data access codes are reused. A few lines of new code are added to provide additional features. WinJS.xhr is used to communicate with the service.
Authentication is handled by Facebook, instead of a local membership database. But Facebook accounts are integrated with ASP.NET membership. WebAuthenticationBroker is used on the client side. On the service side, DotNetOpenAuth is used to handle most authentication logic, while some custom codes are provided to make DotNetOpenAuth work with ASP.NET Web API and WebAuthenticationBroker.
Below are some screenshots for reference.
On the home page, please watch the news list. Customer can use the app bar to sign in.
Sign in using the Facebook account:
If the Facebook account is an administrator, a new app bar command Admin will be displayed. Click it to navigate to the admin/publish pages. Otherwise the user can only add comments to existing news. On the home page, click the header of a group or a news item to go to the detailed pages.
In general, the migration process mainly contains the following tasks.
• Architecture migration: Migrate from traditional 3 tier architecture to SOA. Business logic layer and data access layer can be reused. A new service layer is added (implemented with ASP.NET Web API as a RESTful service). The presentation layer is migrated to a Windows 8 client application. Developers can build additional client applications to consume the same service.• Basic UI migration: Migrate from ASP.NET web forms server controls to HTML controls.• Data presentation UI migration: Migrate from ASP.NET web forms GridView/ListView to Windows 8 ListView.• Presentation logic migration: Migrate from ASP.NET web forms code behind to AJAX invoking ASP.NET Web API.• Authentication migration: Migrate from ASP.NET forms authentication to OAuth. Integrate with Windows 8 WebAuthenticationBroker. Implement federation with popular online identity providers such as Facebook.• Search migration: Migrate from custom search UI to Windows 8 search charm.• Navigation migration: Migrate from web site style navigation to single page navigation. The related links are migrated to Application Bar.• Add more Windows 8 specific features such as Share, Live Tile, Secondary Tiles, etc.