Background

As part of an ongoing project where a light weight client application needs to communicate with a database via a webservice I have been trying to get my head around a the best way to encapsulate data within custom objects and pass it from the client 's GUI to the Web Service's Data Access layer without replicating too much code or having the the client hold a reference to the same assembly as the webservice.

The intention is for the client application to have 3 layers, the presentation layer, a Business Entity / Business Logic layer and an Webservice Adapter layer. The Webservice will have the WebService layer, it's own Business Entity / Business Logic layer and a Data Access layer.

Initial Thoughts

My initial thoughts were to create an assembly which would hold a set of interfaces that will describe the business entities that both parts of the application would use. For example the interface fot the job object would be:

public interface IJob
{
    int Id;
    string CreatedBy;
    DateTime CreatedOn;
    .
    .
    DateTime LastAccessed;
}

This would require that both pairs of business entity assemblies would need to have a reference to the assembly. My plan was then to return from the webservice's webmethods the interface rather than the object. For example.

[WebMethod]
public IJob GetJobById(int id)
{
.
.
}

My plan was then bind the form controls to the properties of the interface but among a couple of minor flaws in my plan, there was one big one... It appears that you can not return an interface from a web service. I assume do to it not being serialisable. A little research later it appears that a better way would be to would be to use a shared base class for the business entities on both sides of the void, so to speak. So back to the drawing board slightly..

Second Thoughts

So now I'm thinking I need to create an abstract base class for the objects in the business entitiy assemblies in both the client and the webservice to inherit from. If I ensure the base classes implement the interfaces, then I can still bind my controls to the interfaces properties. So ignoring the various properties of the class I now have a bas class that implements the previosu

protected abstract class BaseJob : IJob
{
.
.
}

So now the Job class in each business entity layer will inherit from the BaseJob abstract class which implements the IJob interface.

public class Job : BaseJob
{
.
.
}

So this means that now rather than just having a reference to the assembly with the interfaces in for each business entity assembly I now have a reference to the base class assembly too. Is this really the way I want to go?

To be continued...