Budget App - Part 2 : Introducing WCF Into The Picture

Considering that I've been looking at the job market for almost a month now one commonality that all the jobs have had is the requirement for WCF experience. Unfortunately this is something that I haven't had the luck of working with commercially. Even though I've been confident that it would be easy enough to get up to speed, it's difficult to persuade potential employers to see things the same way.

Hence the first thing I wanted to add to my budget application was some WCF services for data access. While my intent is not to go into too much detail on what the ABC's are of WCF services, each of these will, hopefully, be illustrated as I describe how I built and deployed my first WCF services.

Firstly, let's quickly have a look at the changes that were made to the folder structure of the solution.


A number of new projects have been added to the solution, namely: Budget.Business, Budget.DataAccess, and Budget.WCF.

Upon adding a WCF Service Application Visual Studio kindly starts things off for you by including an interface and corresponding class file. It's these files that make up part of the Contract. The interface has the attribute [ServiceContract] and each method definition has the attribute [OperationContract]. Here's what mine looks like.

[ServiceContract]
public interface IIncomeService
{
    ///
    /// Gets all Income objects
    ///
    [OperationContract]
    IList GetAll();
    ///
    /// Gets a single Income object by it's ID
    ///
    [OperationContract]
    Income GetIncomeById( int ID );
    ///
    /// Saves a single Income object, either inserting or updating the records values
    ///
    [OperationContract]
    void Save( Income income );
}

Without these the service will not work. Now you may be wondering what the other part of the contract is? We've now defined what the service can do, now we need to define what can be passed through to the service. This is achieved by adding some new attributes to our data objects. Each class that is to be passed through must have the attribute [DataContract] and each property that is to be access within the class must have the attribute [DataMember]. The data classes to be used were defined in my Linq-to-SQL file which is automatically generated, so any modifications manually made to it would be lost the next time the file refreshed itself. This next bit would have taken me quite a while to figure out were it not for google. You can set the attributes against all the Linq objects by setting the SerializationMode of your DataContext object to Unidirectional.



You will then end up with generated code similar to this:

[Table(Name="dbo.Income")]
[DataContract()]
public partial class Income : INotifyPropertyChanging, INotifyPropertyChanged
{
    ...
    ...
    ...
    [Column(Storage="_IncomeId", AutoSync=AutoSync.OnInsert, DbType="Int NOT NULL IDENTITY", IsPrimaryKey=true, IsDbGenerated=true, UpdateCheck=UpdateCheck.Never)]
    [DataMember(Order=1)]
    public int IncomeId
    {

Once the Contract has been defined the next step is to use them. Here is where all the configuration in the web.config is required. Thankfully as you add services to your project the app.config file is automatically updated by the WCF Service Application project. All you need to do is copy the <system.servicemodel> tag into the appropriate location in the your web.config file.

You should now be able to add the WCF service into your main application via a Service Reference, how ever this is not what I wanted to do. I wanted an extra layer to any business logic I may need and possibly to perform my validation there. Just add another class library, add a Service Reference to this. The app.config file of this new project also contains some extra tags that should be copied over to the web.config of you main app.

Providing you use the WCF Test Client and the default Visual Studio WCF Service Host you should now be able develop your services to your hearts content.

Enjoy!