На вашем месте я бы использовал два разных интерфейса - один для Silverlight (традиционные коммуникации WS) и один для jQuery / JSON.
Класс обслуживания (в нашем случае myService) будет реализовывать оба интерфейса. Пример:
[ServiceContract(Namespace="urn:Cheeso.Samples" )]
public interface IJsonService
{
[OperationContract]
[WebInvoke(Method = "GET",
RequestFormat=WebMessageFormat.Json,
ResponseFormat = WebMessageFormat.Json,
UriTemplate = "search/{name}")]
List<String> JsonSearchByName(String name);
}
[ServiceContract(Namespace="urn:Cheeso.Samples" )]
public interface IWsService
{
[OperationContract(Name="SearchByName")]
List<String> WsSearchByName(String name);
}
[ServiceBehavior(Name="MultiFacedService",
Namespace="urn:Cheeso.Samples")]
public class myService : IJsonService, IWsService
{
public List<String> JsonSearchByName(String name)
{ return SearchByName_Impl(name); }
public List<String> WsSearchByName(String name)
{ return SearchByName_Impl(name); }
public List<String> SearchByName_Impl(String name)
{
var results = List<string>();
// fill results here...
return results;
}
}
Я вижу, что вы не указали явный интерфейс C # для хранения удаленно доступных методов. Подумайте об этом, как я показал в приведенном выше коде. Это помогает, поскольку ваши проекты WCF становятся более сложными.
Можно написать только один набор методов, а затем использовать собственный ServiceHost, чтобы представить интерфейс как Json, так и WS ( См. Пример ). Но это может быть больше работы, чем стоит принять этот подход, и результат может быть менее поддерживаемым.