2013-09-10 6 views
0

Во избежание затрат на обслуживание с использованием служб данных WCF я избегаю генерации ссылок на службы.Не использовать ссылку на службу данных WCF

В настоящее время я использую класс System.Data.Services.Client.DataServiceContext в сочетании с DataServiceQuery. Это работает, но означает, что в коде или конфигурации должны быть некоторые жестко закодированные строки - имя набора объектов и URI.

Каковы альтернативы этому? Любые подводные камни, о которых я должен знать?

я увидел то, что упомянутое создание ChannelFactory

Однако, это выглядело довольно громоздким или, по крайней мере, на поверхности не казалось лучше, что я сейчас делаю.

EDIT Немного более подробно - здесь есть служба, чтобы разоблачить EF DbContext:

public class DocumentService : DataService<DocumentContext> 
{ 
    public static void InitializeService(DataServiceConfiguration config) 
    { 
     config.SetEntitySetAccessRule("Documents", EntitySetRights.All); 
     config.DataServiceBehavior.MaxProtocolVersion = DataServiceProtocolVersion.V3; 
     config.UseVerboseErrors = true; 
    } 

    protected override DocumentContext CreateDataSource() 
    { 
     return new DocumentContext("DocumentsContext"); 
    } 
} 

И как я ссылаться на него без явной ссылки:

new DataServiceContext(uri, maxVersion).CreateQuery<DocumentEntity>(entitySetName)....etc 

Каковы альтернативы этому? = альтернативы классу DataServiceContext

+0

'Это работает, но означает, что должны быть некоторые жестко закодированные строки', если строки могут быть изменены пользователем, вы можете просто сохранить их в файле конфигурации. В любом случае вам понадобятся эти конечные точки для создания ссылки на службу. – PoweredByOrange

ответ

0

Я мог бы использовать:

ObjectQuery - это может быть вручную построен с некоторыми Entity Framework SQL и ObjectContext, который требует строки подключения и поддерживает LINQ к объектам и т.д.

System.Data.EntityClient - это пространство имен также включает в себя некоторые классы для непосредственного взаимодействия с EF. К ним относятся класс EntityDataReader, который возвращает потоковые данные в виде строк и столбцов - подкласс DBDataReader

Как оба метода обходят службу, требуя прямого подключения к базе данных, они имеют ограниченную полезность. Я не пытался их использовать.

1

Конечные точки, контракты (интерфейсы + типы возвращаемых данных) и привязки всегда необходимы в WCF, на самом деле служебная ссылка генерирует их для вас.

Вы можете создать вызов службы WCF с использованием ChannelFactories, однако там будет необходимость делиться информацией, упомянутой ранее между сервером и клиентом.

Там в super good post in stackoverflow about how to create an WCF invoker using ChannelFactory.

Я предлагаю Дарин Димитров ответ.

+0

Спасибо за информацию, но у меня нет контракта явно и я не уверен, что ссылка строго применима. См. Мое редактирование по вопросу. –

+0

обновленный вопрос –

+0

Я вижу. Вы используете ODATA с EF и WCF. URI всегда будет необходим, и я думаю, что имя объекта тоже. Невозможно, чтобы клиент мог волшебным образом определить, где находится сервер, или получить некоторые объекты без указания хотя бы имени – margabit

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