Настройте WCF без использования файла конфигурации и создания экземпляра прокси-клиента с помощью конструктора по умолчанию.

Я не уверен, что это даже возможно, если честно,

Мне интересно, есть ли способ удалить использование файла конфигурации без необходимости переопределять создание клиентского прокси. Позвольте мне привести пример:

В клиентском приложении у нас есть проект WCF DAL. Это оболочка для их сервера WCF, которую может использовать клиентское приложение. В настоящее время клиентскому приложению потребуются все привязки и конечные точки, указанные в файле конфигурации, и обычно (в наших проектах) для обертывания службы WCF необходимо сделать что-то вроде следующего:

public MyObject GetMyObject(int id)
{
    using(var service = new MyObjectDataServiceClient())
    {
         return service.GetMyOBject(id);
    }
}

Это вызовет вызов сервера и вернет объект. Если бы клиентское приложение не имело привязок и конечных точек, оно взорвалось бы. Мы могли бы изменить каждое создание клиента службы данных, чтобы создать привязку и конечную точку, или создать собственную фабрику каналов, чтобы сделать это за нас, но это означает изменение текущего кода слоя WCF DAL.

Моя цель — попытаться создать способ вставки процесса в уровень WCF DAL, который будет обрабатывать привязки и конечные точки без необходимости изменения потребляющего кода, при этом устраняя необходимость в файле конфигурации.

Мои мысли до сих пор состояли в том, чтобы попытаться использовать файл TT, чтобы он создавал частичный класс клиента службы данных и переопределял часть фабрики каналов. Это не удалось, потому что вызов конструктора для клиента службы данных переходит прямо в абстрактный класс (System.ServiceModel.ClientBase‹T›) и пытается получить информацию о конфигурации. Я не смог найти способ остановить его поиск в конфигурации через этот частичный класс и не изменять уровень обслуживания WCF DAL.


person Jon    schedule 30.06.2011    source источник


Ответы (1)


Если у вас есть привязка и конечная точка в DAL, вы можете использовать другой конструктор клиентского класса (тот, который принимает привязку + адрес конечной точки). Этот конструктор полностью обходит конфигурацию, поэтому вам не нужно ничего иметь в конфигурации.

person carlosfigueira    schedule 30.06.2011
comment
Привет, я упомянул в своем посте, что хочу избежать каких-либо изменений в слое DAL. Причина этого заключается в том, чтобы попытаться создать утилиту, которую можно использовать в нескольких проектах для удаления элемента конфигурации, а также проектов, в которых уже настроены клиенты службы. Мое решение на полпути состояло в том, чтобы сделать то, что вы предложили, или использовать фабрику каналов с привязкой и конечной точкой, но это требует изменений в клиентских слоях DAL. Спасибо - person Jon; 01.07.2011
comment
Вам нужно будет где-то передать привязку/адрес, поэтому, если вы не можете изменить существующих клиентов, это нужно сделать на уровне, который создает прокси-серверы WCF. - person carlosfigueira; 01.07.2011
comment
да, именно поэтому я попытался использовать файлы TT для создания частичного класса для каждого клиентского прокси и переопределить его там. Но мне не удалось заставить его прекратить регистрацию и вместо этого использовать мою конфигурацию. - person Jon; 01.07.2011
comment
Да, это не сработает. Вы не можете изменить поведение конструктора в разделяемом классе (текущем клиентском классе) с помощью разделяемого класса. К сожалению, у вас есть два варианта: либо изменить DAL (вы даже можете добавить некоторую логику, чтобы определить, есть ли конфигурация, и если да, продолжить ее использование, передав '*' конструктору, который принимает имя конфигурации конечной точки), поэтому предварительно - существующие клиенты не будут сломаны или изменены сами клиенты. - person carlosfigueira; 01.07.2011
comment
Вот к такому выводу я пришел. Я надеялся, что в классе servicemodel.clientbase могло быть что-то, что я мог пропустить, что я мог бы как-то настроить (не знаю, как, и это было далеко), чтобы избежать этого. Спасибо за вашу помощь и совет. - person Jon; 01.07.2011