WCF Design Approach

Question

In my solution I have a Web application project and a Class library project that contains all the business logic and this also acts as a data access layer as I am using Entity Framework. This means that I have my edmx in this layer itself.

I have some 34 classes in this class library project and at an average 6 public methods in each class. These classes were getting called directly from the web application until now. No problems. Now I want to introduce the WCF Layer between the UI and the Business logic layer.

This means I will have to write wrapper methods for all my methods and expose them in a WCF Service. Does this mean that 34 * 6 = 204 methods (approximately) will appear in my service layer as Operation Contracts? As per OO, I think this is too large a class and so it feels wrong.

I know there is the Generic Service design pattern, but is there anything else that I am missing? Please advise.

Answer 1

Well,

We have a similar application but the number of classes is even higher. Your concern here is that you are reluctant to provide serialization (that is what is needed to pass objects by WCF) to core classes of your business logic server.

Provided you have a classical three-tier application where business logic server and a client access the same database. What you need to do is simply 1) ensure all your objects have a unique identification (this could be a string or Guid) and 2) pass object ID in all WCF calls. What that means is that you DO NOT expose any classes on WCF side.

This might be quite is safer since you have a web application.

Answer 2

You could try RIA services

http://www.silverlight.net/getstarted/riaservices/

What I'm using is this.

1. Create a WCF service

2.1. Point the SVC service to your implementation like:

<%@ ServiceHost Language="C#" Debug="true" Service="BusinessLayer.Service" %>

BusinessLayer.Service is a class in your Class project. (reference in service is needed)

2.2. Point the service behavior to the contract:

<service behaviorConfiguration="ServiceBehavior" name="BusinessLayer.Service">
        <endpoint address="" binding="basicHttpBinding" bindingConfiguration="basicHttpBinding" contract="BusinessLayer.IService">
          <identity>
            <dns value="localhost"/>
          </identity>
        </endpoint>
      </service>

Edit the name (BusinessLayer.Service) and contract (Businesslayer.IService)

1. Create the contract interface BusinessLayer.IService (in your Class project):

   namespace BusinessLayer { [ServiceContract] public interface IService { [OperationContract] void DoWork(); } }

2. Modify the existing implementation which uses the interface (here is your existing code):

   namespace BusinessLayer { public class Service:IService { Public void DoWork() { } } }

Answer 3

Why do you want to wrap the entire business logic layer in a WCF layer? I would look very closely at your reasons for this before jumping into this new approach. Do you have physical reasons that you simply can't get around like the business logic that accesses the database needing to be outside the DMZ? If so, ok. But if not, I'd think twice about going down this approach to start with.

Having said that, if you have no other choice, I'd avoid the monolithic WCF class that wraps every public method that your UI needs. First off, I'd introduce an interface on the web application side so that you can depend on abstracts in the UI rather than concrete implementations. Further, I'd look into using WCF REST services. You can use ServiceRoute's to avoid having to introduce any *.svc files. Then you can decorate the methods you want to expose with WebGet/WebInvoke attributes. This could potentially save a lot of coding.

Answer 4

It is wrong. Your services should not have much more than 20 operations. If you need exactly same operations you should create contract and service wrapper for each business class. This usually results in chatty interfaces which are not good solution for distributed scenario. In that case you should model your service layer as facade which compounds several calls into one.