o

Once you made those decisions and started writing your app you were forced to learn a new protocol {.Net Remoting, ASMX web services, MSMQ, Named Pipes, etc.} and implement a solution specific to that API. The problem with this is that your code doesn’t age gracefully. If the requirements change too much, you need to rewrite the entire communication layer using an API which supports whatever mission-critical feature you need.

WCF fixes this problem and more by providing a unified programming model for all the above scenarios so you now just have to learn one API and toolset. It does this by separating the various pieces of communication, E.g., protocols, message contracts, etc. Rather than worrying about the specifics of how each message is transferred between client and server, WCF just asks you to focus on the service and message contracts. That is, what methods will you be able to call from a client and the structure of the data returned. All the goo about communication protocols is highly configurable and out of code (in the app.config). That is WCF from a mile-high view, but let’s dive into what it can do for you in Visual Studio 2008.

We will be creating a three-tiered application called Northwind Traders. Our solution will comprise of four projects: a data access layer, a WCF service, a WinForms client, and a shared business logic component. Along the way we will highlight key features new to Visual Studio 2008 and demonstrate just how easy it is to write killer data-centric apps.

Let’s start our app by creating a data access layer by creating a new class library aptly titled DataAccessLayer.

One of the common problems developing N-tier applications in Visual Studio, is that the tools put the TableAdapters and the typed DataSets in the same project. Which unfortunately leaks out sensitive information such as connection strings. If you wanted to reuse your typed DataSets but keep your TableAdapters private, you have to resort to fighting against the tools which doesn’t provide a great developer experience. Fortunately in Visual Studio 2008 we’ve addressed this.

Once you’ve created the data access layer in Visual Studio 2008 you can configure the DataSet Designer to generate the DataSet code into a separate project in your solution. So you can share/reuse your typed DataSets without exposing things like connection strings.

Add another class library project to your solution called NorthwindBuisnessObjects.

Imports NorthwindBuisnessObjects

Public Class NorthwindManager

    Public Shared Function GetCustomers() As NorthwindDataSet.CustomersDataTable

        Dim customerAdapter As New NorthwindDataSetTableAdapters.CustomersTableAdapter()

        Return customerAdapter.GetData()

    End Function

    Public Shared Function GetOrders() As NorthwindDataSet.OrdersDataTable

        Dim orderAdapter As New NorthwindDataSetTableAdapters.OrdersTableAdapter()

        Return orderAdapter.GetData()

    End Function

End Class

Now let’s move onto creating our WCF service. The tooling support should be on par with the ASMX Web Reference experience. Let’s begin by creating a new WCF Web Service project, which creates a new WCF service hosted in IIS.

Once our service project has been created, let’s add references to both our DataAccessLayer and BuisnessObjects projects.

Next, let’s replace the default service contract from the project template with our own. Those <ServiceContract()> and <OperationContract()> interfaces indicate to the WCF runtime that this is a WCF service contract.

Imports NorthwindBuisnessObjects

<ServiceContract()> _

Public Interface IService

    <OperationContract()> _

    Function GetCustomers() As NorthwindDataSet.CustomersDataTable

    <OperationContract()> _

    Function GetOrders() As NorthwindDataSet.OrdersDataTable

End Interface

Imports NorthwindBuisnessObjects

Imports DataAccessLayer

Public Class Service

    Implements IService

    Public Function GetCustomers() As NorthwindDataSet.CustomersDataTable Implements IService.GetCustomers