WCF and Class Libraries

Question

We are delivering services over WCF. Our data in SQL Server is exposed using Entity Framework, Automapper and DTOs.

We are comfortable in providing attributes in the DTOs, but are unsure how to implement the other methods, which we would like to hold in a Class Library.

Rather than put all the methods for the whole service in a single WCF Service Implementation we would like just reference the methods which are implemented in a Class library.

How do we implement the Business Logic Layer through a Class Library, exposed to the Presentation Layer through WCF and using DTOs to pass the data around?

Do the exposed class methods some how refer to the DTOs? Should the Class Libraries be split by layer?

Service Element

[ServiceContract]

public interface Interface1
{
    [OperationContract]
    Class1 GetClass1(int id);

    [OperationContract]
    Class2 GetClass2(int id);
}

Class Library Element

public class Class1 : Interface1
{
    public Class1 GetClass1(int id) { 
        // implementation

    }
}

public class Class2 : Interface1
{
    public Class2 GetClass2(int id)
    {
        // implementation

    }

}

DTOs

[DataContract]
public class Class1
{
    [DataMember]
    public int x { get; set;}
}

[DataContract]
public class Class2
{
    [DataMember]
    public int y { get; set;}
}

Answer 1

If I understand your question correctly. you donot want all your methods which are exposed auotomatically. If you want to abstract only few methods then you have share common DTO’s in both service and class service aswell.

Answer 2

Yes, you can use a class library for a WCF service (there's a project in Visual Studio under WCF for WCF Class Library). This class library would hold the implementation of the service contract - the service contract could be defined in the class library as well, or could be in another assembly that the class library references.

This class library then in turn needs to be hosted (IIS, self-hosted or Windows Service). We do this at work - we have an n-tier application that uses WCF to communicate between the layers, and all of the services themselves are implemented in a class library, and hosted (usually in IIS, in one case in a Windows Service).

Taking a modified version of your posted code (you should have different names for you implementing classes and your DTOs), you could do something like this:

Class Library

[ServiceContract]
public interface Interface1
{
    [OperationContract]
    Class1 GetClass1(int id);

    [OperationContract]
    Class2 GetClass2(int id);
}


public class Service1 : Interface1
{
    public Class1 GetClass1(int id) 
    { 
        // implementation
    }

    public Class2 GetClass2(int id)
    {
        // implementation
    }
}

Note that there is one service class, and it implements the two Operation Contracts defined in the service definition (Interface1). You code as posted would not compile because neither class implemented both methods defined in the interface (you would also get at the very least a warning on the class names because of their return types as well).

You could then add a reference to this class library to the assembly you have your DTOs (Class1 and Class2) in.

To host this in a self-hosted scenario or a Windows service you would need a reference to the class library (Service1 in my example) and a reference to the DTO assembly as well. Then you would instantiate a service host for the service, like this:

baseAddress = new Uri("some address");

ServiceHost myHost = new ServiceHost(typeof(Service1), baseAddress);

myHost.Open();

To host in IIS, you'd modify the .svc file markup like this:

<%@ ServiceHost Language="C#"
                Service="MyCompany.Service1"
                Factory="System.ServiceModel.Activation.ServiceHostFactory" %>

You'll want to fully qualify the service name with the complete namespace, so assuming the namespace for Service1 was MyCompany the fully-qualified name would be MyCompany.Service1.

Finally, you will need to put the relevant system.serviceModel section in the corresponding hosting application's app.config or web.config file, as libraries use the config files of their consuming application, not their own.

There's a number of subtle variations on this theme (in our case, we use a custom service host and custom service host factory, and the interfaces - service contracts - are in a separate assembly, which allows us to create proxies via ChannelFactory<T>.

To answer your final question, the class library(ies) will have to reference the assembly that contains your DTOs if they are going to use them, and you can split your service class libraries however you deem fit for your requirements - I would definitely split them at least by layer, and possibly by vertical stack as well, if you have multiple applications.

Answer 3

Let me first clarify what (I think) you are trying to do:

You have some business logic that you wish to expose over WCF, which will ultimately be consumed by your presentation layer. The business logic involved accessing a database and using an ORM and AutoMapper. For the purposes of your question I believe the details of this implementation are irrelevant.

Let us do a first iteration of what that would look like (I would separate out the different namespaces in to different assemblies):

namespace Contracts
{
    [ServiceContract]
    public interface IMyService
    {
        [OperationContract]
        Data GetData(int id);
    }

    [DataContract]
    public class Data
    {
        [DataMember]
        public string PropertyValue { get; set; }
    }
}

namespace ClassLibrary
{

    public class BusinessLogicImplementation: IMyService
    {
        public Data GetData(int id)
        {
            /**
             * Do data retrieval here, which returns returnedData
             * */
            DataModel returnedData;
            return Mapper.Map<DataModel, Data>(returnedData);
        }
    }
}

namespace EntityFrameworkModel
{

    public class DataModel
    {
        public string PropertyValue { get; set; }
    }
}

The Contracts assembly contains data that is public to both the service and the clients. This can be consumed by the client either by a binary reference to the assembly, or by the client having their own local implementation of the contracts (like a Visual Studio service reference).

The Class Library assembly contains the implementation of your data retrieval and business logic. I have also shown the Data Model - but only for extra context - I don't think this is relevant to your question:

So far we have answered part of your question:

"How do we implement the Business Logic Layer through a Class Library, exposed to the Presentation Layer through WCF and using DTOs to pass the data around?"

Next let us consider the first part of your query:

"Rather than put all the methods for the whole service in a single WCF Service Implementation we would like just reference the methods which are implemented in a Class library."

Although you do not suggest it explicitly, this suggests that your WCF service is exposing more methods than is relevant to your client. Quite rightly you want to make the interface your client sees concise and relevant to what they want to achieve.

This is achieved by exposing different endpoints on your service represented by different interfaces. In terms of the code, I add an extra layer between the implementation of the business logic and the implementation that is exposed over WCF:

namespace Contracts
{
    [ServiceContract]
    public interface IMyService
    {
        [OperationContract]
        Data GetData(int id);
    }

    [DataContract]
    public class Data
    {
        [DataMember]
        public string PropertyValue { get; set; }
    }
}

namespace MoreContracts
{
    [ServiceContract]
    public interface IOtherService
    {
        [OperationContract]
        MoreData GetMoreData(int id);
    }

    [DataContract]
    public class MoreData
    {
        [DataMember]
        public string MorePropertyValue { get; set; }
    }
}

namespace Service
{
    /**
     * This class adds an extra layer between the exposed functionality and the implementation.
     * It effectively is used for hosting all the business logic you want to expose over the service,
     * including that contained in ClassLibrary and anywhere else.
     * */
    public class ServiceImplementation: IMyService, IOtherService
    {

        public Data GetData(int id)
        {
            return new BusinessLogicImplementation().GetData(id);
        }

        public MoreData GetMoreData(int id)
        {
            //Implementation of logic not in class library
        }
    }
}

namespace ClassLibrary
{
    public class BusinessLogicImplementation : IMyService
    {
        public Data GetData(int id)
        {
            /**
             * Do data retrieval here, which returns returnedData
             * */
            DataModel returnedData;
            return Mapper.Map<DataModel, Data>(returnedData);
        }
    }
}

A quick search online will show you what you need to do to host a service with multiple endoints for your hosting scenario. E.g. for self hosting see Run WCF ServiceHost with multiple contracts.