Although he solved it quite nicely a different discussion sprouted from it. How would you develop a WCF service that returns a datacontract on which some members are lazy loaded over WCF and would you actually do this?
I remembered working on a project where they had some kind of mechanism that resembled it but the experience was rather unpleasant as they used their entities as DTO's which was ugly and caused all kinds of problems. Ah ... I think I just found the topic of my next post.
To answer the first question, how would you do it, well here's how I would do it.
The gist of it is to have your datacontract use a servicelocator or perhaps better an IoC containter to resolve the interface of the service contract that fetches the children. On the server the implementation of this interface could for example fetch the children from the database. On the client it would call the service responsable for fetching the children.
So let's have a look at the datacontract from the parent.
[DataContract]
public class Parent
{
[DataMember]
private IList<child> _children;
public IChildServices ChildService
{
get { return ServiceLocator.SillyServiceLocator.GetInstance<ichildservices>(); }
}
[DataMember]
public int Id { get; set; }
[DataMember]
public String Name { get; set; }
public IList<child> Children
{
get
{
if (_children == null)
{
_children = ChildService.GetChildren(Id);
}
return _children;
}
}
}
Note the "Children"-getter where we check if the children still have to be loaded and if so the service locator is queried for the implementation of the IChildServices and the GetChildren method is executed on it.The implentation of the IChildServices on the client would look as folows.
public class ChildServicesProxy : ClientBase<ichildservices>, IChildServices
{
public ChildServicesProxy() : base("ChildService")
{
}
public IList<child> GetChildren(int parentId)
{
return Channel.GetChildren(parentId);
}
}
Here we see the GetChildren method calls the GetChildren wcf call.
The IChildServices is also implemented on the server
public class ChildServices : IChildServices
{
#region IChildServices Members
public IList<child> GetChildren(int parentId)
{
//hardcoded but could fetch the children from the database
if(parentId == 1)
{
return new List<child>
{
new Child
{
Name = "Parent 1 - Child 1"
},
new Child
{
Name = "Parent 1 - Child 2"
}
};
}
if(parentId == 3)
{
return new List<child>
{
new Child
{
Name = "Parent 3 - Child 1"
}
};
}
return new List<child>();
}
#endregion
}
Here the actual fetching of the data happens. In this case the data is hardcoded but a call to some persistent store could be called here.
The only thing we have to do now is register the implentation of each IChildServices on to the serviceloactor of the client and the server at startup of the applications.
Perhaps more interesting, at least for me, are the pros and cons of using such an approach.
I definitely wouldn't use it by default and it should be very obvious for the consumer he's using a lazy loaded contract as it obviously does imply a major performance hit that one would not immediately link to dereferencing a property.
On the other hand if, at the client side, you map your datacontract on a client-domain I guess it makes more sense to fetch all the data you need at once before mapping it.
Anyway my conclusion is that I would only use this in very specific cases while making more than obvious that the datacontract is a lazy loaded one.
You can find a working version of it here. Please note that it has been stripped down for simplicity reasons.
What are the pros and cons according to you? Would you use this approach and if so in which cases?
