2011-01-11 3 views
2

У меня есть модель EF4 с хранимой процедурой, которую я хочу вызвать от клиента. Серверный код выглядит следующим образом:Вызов функции WCF DataService [WebGet] от клиента

[WebGet]   
public IQueryable<SalesData> GetSalesReport(int reportType, int yr, int m, int d) 
{ 
    DateTime dt = new DateTime(yr, m, d); 
    return this.CurrentDataSource.RP_SalesReport(reportType, dt, dt).AsQueryable<SalesData>(); 
} 

При вызове с помощью IE, используя URL-адрес «HTTP: // локальный: 12345/MyService.svc/GetSalesReport = 1 Тип уведомления & год = 2009 & м = 4 & d = 2 "работает так, как ожидалось.

В моем клиентском приложении я добавил ссылку на Службу (http: // localhost: 12345/MyService.svc) и то, что я попробовал, функция «GetSalesReport» не отображается в обозревателе объектов. (Нормальные объекты EF отображаются в обозревателе объектов)

Так что мой вопрос: как я могу назвать эту функцию у клиента?

И есть ли разница в том, как вызвать эту функцию в зависимости от клиента (я хочу вызвать эту функцию из приложения Silverlight Silverlight, но сейчас я тестирую с помощью тестового клиента WPF).

+0

Какие атрибуты вы ассоциировали с этим методом в ServiceContract? –

+0

Это служба данных ADO.NET (кодовое имя «Astoria»), и единственным атрибутом, который у меня есть, является [WebGet]. Насколько я знаю, вы не можете добавить [ServiceContract] в службу данных ADO.NET. – Ronny

+0

Вы проверили сгенерированный код? У вас должен быть огромный файл с сгенерированными объектами. У него есть запись для GetSalesReport и как она выглядит? –

ответ

5

На самом деле это похоже, что ADO.NET DataTeam не реализовал CodeGen для вызова ServiceMethod с клиента.

Так soloution к моей проблеме, чтобы написать этот код на клиенте:

 // execute the service operation 
     Uri u = new Uri(string.Format("{0}/GetSalesReport?reportType={1}&yr={2}&m={3}&d={4}", 
         context.BaseUri, 1, 2009, 4, 2),UriKind.RelativeOrAbsolute); 

     var datas = context.Execute<SalesData>(u); 

Благодаря Gil Fink, который написал эту запись в блоге: http://blogs.microsoft.co.il/blogs/gilf/archive/2008/11/14/consuming-data-services-service-operations.aspx

+1

Этот сценарий может привести к другой проблеме: в настоящее время прокси-серверы, созданные OData, не поддерживают сложные типы, а только типы объектов. Это означает, что в случае, если SalesData определяется как сложный тип (элемент «ComplexType» в CSDL), генерируемый OData ответ не будет отформатирован как фид. Обходным путем является определение сложного типа как объекта, что может потребовать определения поддельных таблиц. –

Смежные вопросы