Home > WCF > A Practical Architecture for WCF – Part 2

A Practical Architecture for WCF – Part 2


This article follows A Practical Architecture for WCF – Part 1.

Whew, well finally (no really) some code! 

I created an empty solution called CheeseList_3_0_0_x and created all of my projects inside of it.  Call it whatever you want.  In my solution I created a project for my services called CheeseListServices and then created three services, one each for Brands, CheeseTypes and Links. 

I structured my project so that each service was in its own folder.  I did this so that nothing happens by default.  What I mean by that is that all the examples presented by books and blogs just show one service, but, most projects will have more than one service and it took me a long time (blush) to figure out how to do this in an industrial strength way, so I am starting you out that way in the beginning.

The steps to do this after creating your blank solution is to highlight the solution and then add and then new project.  Since we are coding in C# here, under the Visual C# header in the Project types list click on WCF and then click on WCF Service Library.  I named mine CheeseListServices.

Create Services Project

After creating your Service project, please delete the Service1.cs and IService1.cs files in the root of the project that were created by default.  Leave App.config alone for now.  Then, create a few folders for your services.  We are mostly going to only use one, but the other services will have one or two methods in them so you can tell for sure that everything is setup correctly and what you are calling is actually answering.  After you have created your folders, create the services you’ll be using, one service to a folder so that everything that relates to that service is in one place.

To create your services, click on the folder in your services project and then goto add and then new item.  In the Templates window click on WCF Service.   Give it a name that makes sense to you.

Create Services  

You’ll notice that only two files were created, one will house service interfaces and the other will house the actual services.  We are going to need to add a third for data contracts.

In your references section add a reference to System.ServiceModel and make sure that you have a using statement for it in all of your services files.  In addition, since I am wrapping an existing website I also added references to my datalayer, businesslayer and common dll’s from that project.  The next step is to create the data contract to support your first example. 

I chose the most simple, non-transactional, routine with no parameters I could think of to start small and that was to return a list of all brands.  The business layer of the site has a brand object with a ListAll() method with no parameters, so this is my starting point.   I would pick something very simple with no parameters or transactions and that returns something simple, like a list.

My data contracts for BrandServices is in a file called BrandDataContracts.cs.  At this point please create a data contract that will contain the types in your service.  Lets take a look at a snippet of code from my data contracts file for the Brand service, and walk through what is there and why.  Basically I am going to want to return a list of brands that will contain an numeric ID of a brand and a label.  There is much more to this file that we will go through later.

BrandListDataContract

Let’s take a look at what we did.

We created an object called BrandList and decorated it with the DataContract attribute.  And as a parameter to that attribute, we are providing a string that is formatted with the URL of the service, the service type and then a year and a month.  This string will uniquely identify the service in metadata so think this through carefully as it will be very helpful to have something structured that will allow you to uniquely identify your data contracts as well as something that can indicate when they were created.

Next we have our private properties just like any object.  Here we created properties for a brand id, a label and an error level.

For constructors, we are allowing the creation of an a BrandList object with or without parameters.  Each constructor is also calling an init method we will use to set default and other values.  In this case we are setting the default value of the error level to an init status – that is neither success or fail.

In the public properties section, we are exposing our private properties through get/set variables and then are decorating each with a Name, Order and IsRequired.  This decoration is important because it is used in meta data when the objects properties are exposed.  If you do not list an order, properties will be displayed in alpha order which may not be the best way.   IsRequired is important because if something is set as IsRequired equals true and it is not present, an exception will be thrown.  When IsRequired equals false, the variable is optional.

That’s it – we have created our first data contract.  Now lets go and write the service.

Open the interface file for your service.  In my case its IBrandServices.cs.  We are going to create an interface for our Brand service and will expose a method to list all brands, or ListAll().  Please refer to the image below.

BrandListOperationContract

Lets look at what we did and why.

In our namespace, it’s just like before with our data contract with one difference.  In this case we are creating a Service Contract. 

The one method we want to expose at this point in our service will be that list of all brands, so here we create an interface for a ListAll() method that returns a List<BrandList>.  The BrandList type in our List<> is the object we created in our data contract.

Next, lets create the actual service.  In my case I created a BrandServices.cs file.  Let’s take a look and see what was done.

 BrandListService

We created a public object called BrandServices and derived it from our interface IBrandServices.  We have one public method called ListAll() that returns a List<BrandList>.  The first thing we do is to create a new brand object of type List<BrandList> and then call the ListAll() method in the business layer of the existing web site.

Since that application has been a self contained web site, we used DataTables for passing our data around.  This is not a problem because all of the .NET controls can data bind to them.  However DataTables will not work for services.  We need strongly typed data. 

Let’s take a step back for a minute to understand why we need strongly typed data.  One of the crown jewels of using WCF to implement services is in the mechanism for a standard in the creation of metadata files that can be consumed by any application using our service, or in a word, interoperability.  That is, you could write services in .NET and they can be consumed by a Java app or vice versa.  But the calling application must have a way to find your service and then to understand the details of your service, operation, data and fault contracts.

I don’t want to get too deep here as the references linked to the first post in this series cover this in detail, but when we look at the metadata for the return value for the List<BrandList> it is seen as a BrandList[].  One side of the service can use all of its types but as long as they are translated and handled by metadata the calling application can consume them.

One more aspect of types.  There is a generic type of collection available in the ServiceModel namespace that you can use instead of List<>.  This is valuable because the program using the service may not know what a List<> is but needs a collection it can insert objects into to pass them back to you.  We’ll get into this a little later, but if you create a data type based on an ObservableCollection<>, the client can create that type, fill it and send it back.

Ok, back to our code.  After checking the error level and row count from the call to the ListAll() method exposed by the original business layer, for each data row in the returned data table, we are creating a new BrandList object and adding it to the brands list.  If we do not throw an exception, we return the brands list.

For now I am going to skip exception handling, but will get back to it later after we get this service working.  So you can copy and paste my catch block.

Ok, so to review, we created our solution and then created a project to house our services.  We created one service that is consuming a method from an existing application and are supporting it with a data contract and an operation contract.

The next step will be to host the service so we can work with it, and we’ll do that in the next article.  In that post we will learn how to set up IIS7 to host a service using the net.tcp protocol which is much faster than http and can feed either a website or a windows form application equally well.

Advertisements
  1. No comments yet.
  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: