Проблема WCF с прокси-классом против реального класса - PullRequest
1 голос
/ 02 октября 2009

У меня есть служба WCF, которую использует мое консольное приложение. Создается прокси-класс, который использует пространство имен консольного приложения.

Уровень DataAccess имеет метод GetItems, для которого требуется объект ITEM, принадлежащий другому пространству имен. В любом случае нужно сказать WCF создать элементы, которые принадлежат определенному пространству имен, и не использовать клиентский проект для создания пространства имен!

UPDATE

Вот проблема:

// The following namespace belongs in the class library project 
MYProject.Something.Foo foo = new Foo(); 
foo.Text = "hello world"; 

// Now the webservice has a method ProcessFoo but the proxy 
// class shows something like this: 
ProcessFoo(MyClientProject.Something.foo); 

Я не могу отправить свой MYProject.Something.Foo в метод ProcessFoo.

Ответы [ 4 ]

2 голосов
/ 02 октября 2009

Будет ли эта служба вызываться только клиентами .NET WCF? Если это так, то при создании ссылки на службу вы можете указать WCF предоставить общий доступ существующему типу, а не создавать прокси-версию возвращаемого типа.

Конечно, это будет работать только с клиентом WCF. Любой другой тип клиента должен будет использовать прокси-класс, в котором вы, похоже, находитесь.

См. Основы: как работают веб-сервисы для объяснения. Первоначально я писал о веб-сервисах ASMX, но в целом это относится к веб-сервисам.

0 голосов
/ 02 октября 2009

Я собираюсь предложить альтернативу тому, что вы пытаетесь сделать:

Вместо того, чтобы переделывать свой код, чтобы вы передавали свой класс MyProject.Something.Foo через веб-сервис, я предлагаю НЕ делать этого. И вот почему:

Используя класс MyProject.Something.Foo в контракте на обслуживание, вы тесно связываете класс с вашим веб-сервисом и, следовательно, также связываете клиентов вашего веб-сервиса, которые должны будут генерировать свои собственные прокси на стороне клиента (или эквивалент). Эта связь затрудняет вам изменение реализации логики, скрытой за вашим контрактом на обслуживание в будущем, потому что, если вы сделаете изменение, которое включает в себя изменение открытого интерфейса класса, вам придется заново сгенерировать прокси-серверы и изменить Контракт опубликован вашим веб-сервисом. Как и все ваши клиенты.

Вместо этого я предлагаю вам сгенерировать прокси с помощью svcutil; сохраняйте класс MyProject.Something.Foo (который является вашим слоем Business Logic) отдельным; и написать немного кода для сопоставления между ними. В этом случае вы с большей вероятностью сможете воспринимать изменения в своем классе бизнес-логики, не нарушая и не создавая заново контракт на обслуживание.

То, к чему я (не очень красноречиво, прочитав это обратно) пытаюсь добраться, - это принцип разработки SOA, известный как «Схема общего доступа к службам и контракт, а не класс» - дайте этому Google и посмотрите, что вы думаете.

Надеюсь, это полезно!

0 голосов
/ 02 октября 2009

Вы можете создавать псевдонимы классов, используя оператор импорта, избегая конфликтов имен:

import MyProject; // MyProject.Something
import ServiceSomething = MyClientProject.Something;

Теперь вы можете ссылаться на оба типа из одного и того же файла класса / кода, ссылаясь на прокси-класс службы как ServiceSomething.

Редактировать: Я действительно рекомендую вам , а не делиться своими сущностями с прокси веб-службы. Это делает управление версиями намного сложнее. Просто создайте статический класс SomethingMapping, который отображает экземпляры туда-сюда и затем никогда не использует прокси-класс веб-службы вне класса, который использует прокси.

0 голосов
/ 02 октября 2009

UPDATE

Оказывается, я полностью неправильно понял ваш первоначальный вопрос. Вы можете либо вручную скопировать свойства вашего объекта MYProject.Something.foo в MyClientProject.Something.foo, либо, если вы часто используете эту операцию, вы можете реализовать какую-то подпрограмму преобразования, чтобы вы могли выполнить:

MYProject.Something.Foo foo = new Foo(); 
foo.Text = "hello world"; 

ProcessFoo((MyClientProject.Something.foo)foo);

ORIGINAL

Каждый раз, когда вы создаете объект, вы всегда можете использовать его полное имя для указания пространства имен:

SqlConnection conn = new SqlConnect();

эквивалентно

System.Data.SqlClient.SqlConnection conn = 
    new System.Data.SqlClient.SqlConnection();
Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...