If you’re building Silverlight applications that consume data then you’re probably making calls
to Web Services. We’ve been successfully using WCF along with Silverlight for several client Line of Business (LOB) applications and passing a lot of data back and forth. Due
to the pain involved with updating the ServiceReferences.ClientConfig file generated by a Silverlight service proxy (see Tim Heuer’s post on that subject
to see different ways
to deal with it) we’ve been using our own technique
to figure out the service URL. Going that route makes it a peace of cake
to switch between development, staging and production environments.
To start, we have a ServiceProxyBase class that handles identifying the URL
to use based on the XAP file’s location (this assumes that the service is in the same Web project that serves up the XAP file). The GetServiceUrlBase() method handles this work: public class ServiceProxyBase
{
public ServiceProxyBase()
{
if (!IsDesignTime)
{
ServiceUrlBase = GetServiceUrlBase();
}
}
public
string ServiceUrlBase { get; set; }
public static bool IsDesignTime
{
get
{
return (Application.Current == null) || (Application.Current.GetType() == typeof (Application));
}
}
public static
string GetServiceUrlBase()
{
if (!IsDesignTime)
{
string url = Application.Current.Host.Source.OriginalString;
return url.Substring(0, url.IndexOf("/ClientBin", StringComparison.InvariantCultureIgnoreCase));
}
return null;
}
}
Silverlight 4 now supports relative paths
to services which greatly simplifies things. We changed the code above
to the following:
public class ServiceProxyBase
{
private const
string ServiceUrlPath = "../Services/JobPlanService.svc";
public ServiceProxyBase()
{
if (!IsDesignTime)
{
ServiceUrl = ServiceUrlPath;
}
}
public
string ServiceUrl { get; set; }
public static bool IsDesignTime
{
get
{
return (Application.Current == null) || (Application.Current.GetType() == typeof (Application));
}
}
public static
string GetServiceUrl()
{
if (!IsDesignTime)
{
return ServiceUrlPath;
}
return null;
}
}
Our ServiceProxy class derives from ServiceProxyBase and handles creating the ABC’s (Address, Binding, Contract) needed for a WCF service call. Looking through the code (mainly the constructor) you’ll notice that the service URI is created by supplying the base path
to the XAP file along with the relative path defined in ServiceProxyBase:
public class ServiceProxy : ServiceProxyBase, IServiceProxy
{
private const
string CompletedEventargs = "CompletedEventArgs";
private const
string Completed = "Completed";
private const
string Async = "Async";
private readonly CustomBinding _Binding;
private readonly EndpointAddress _EndPointAddress;
private readonly Uri _ServiceUri;
private readonly Type _ProxyType = typeof(JobPlanServiceClient);
public ServiceProxy()
{
_ServiceUri = new Uri(Application.Current.Host.Source, ServiceUrl);
var elements = new BindingElementCollection
{
new BinaryMessageEncodingBindingElement(),
new HttpTransportBindingElement
{
MaxBufferSize = 2147483647,
MaxReceivedMessageSize = 2147483647
}
};
// order of entries in collection is significant: dumb
_Binding = new CustomBinding(elements);
_EndPointAddress = new EndpointAddress(_ServiceUri);
}
#region IServiceProxy Members
/// <summary>
/// Used
to call a WCF service operation.
/// </summary>
/// <typeparam name="T">The type of EventArgs that will be returned by the service operation.</typeparam>
/// <param name="callback">The method
to call once the WCF call returns (the callback).</param>
/// <param name="parameters">Any parameters that the service operation expects.</param>
public void CallService<T>(EventHandler<T> callback, params object[] parameters) where T : EventArgs
{
try
{
var proxy = new JobPlanServiceClient(_Binding, _EndPointAddress);
string action = typeof (T).Name.Replace(CompletedEventargs,
String.Empty);
_ProxyType.GetEvent(action + Completed).AddEventHandler(proxy, callback);
_ProxyType.InvokeMember(action + Async, BindingFlags.InvokeMethod, null, proxy, parameters);
}
catch (Exception exp)
{
MessageBox.Show("Unable
to use ServiceProxy.CallService
to retrieve data: " + exp.Message);
}
}
#endregion
}
The relative path support for calling services in Silverlight 4 definitely simplifies code and is yet another good reason
to move from Silverlight 3
to Silverlight 4.
For more information about onsite, online and video training, mentoring and consulting solutions for .NET, SharePoint or Silverlight please visit http://www.thewahlingroup.com.
