Хорошо. У меня есть некоторые концептуальные проблемы с сервисом WCF, который я хочу создать. Короче говоря, мне нужно создать отдельную службу Windows, которая предоставляет мне функциональность удаленного взаимодействия (заменяя приложение удаленного взаимодействия .NET 1.1).
Некоторые общие понятия, которые я сейчас понимаю:
- Я могу сделать это, сначала создав консольное приложение, которое обеспечивает функциональность хостинга WCF.
- Затем я бы развернул это консольное приложение в качестве службы с помощью механизма «создания службы», доступного для .NET (используя IDE, это довольно просто - эта часть не сложна).
Редактировать: может быть, лучше просто создать службу Windows, открыть хост службы в OnStart () и закрыть его в OnStop (). Я, вероятно, сделаю это, но одна вещь, которую я нахожу запутывающей, состоит в том, что некоторые примеры, на которые я смотрю, говорят о написании простого консольного приложения в сравнении с этим механизмом ....
Вот текущая ситуация. У нас есть интерфейс, я назову его IData, который реализует наши вызовы к серверу SQL. В настоящее время мы реализуем IData в классе, который я назову RemData, у которого есть наши основные методы Execute_Query и Execute_NonQuery.
Следовательно, IData выглядит так:
[ServiceContract()]
public Interface IData
{
[OperationContract()]
int Execute_Query( parameter list....); // parameter list shouldn't be important here I hope.
[OperationContract()]
int Execute_NonQuery( parameter list....);
}
Обратите внимание, как в определениях моего интерфейса я добавил атрибуты для материала WCF (Service Contract и OperationContract). Это главное в одном из моих вопросов ниже.
RemData реализует IData. Мы строим его отдельно как DLL.
Теперь мне нужно изменить WCF, чтобы я создал консольное приложение и включил ссылку на библиотеку DLL, содержащую определение для моего интерфейса IData, и ссылку на библиотеку DLL для RemData (да, они находятся в двух отдельных сборках для меня ).
Вот сложная часть для меня. Мне нужно улучшить сервис, поэтому я думаю, что смогу сделать это таким образом. Сначала я изменяю класс RemData и добавляю System.ServiceModel в качестве ссылки, а затем украшаю класс атрибутом [ServiceBehavior ()], а затем добавляю атрибуты [OperationBehavior ()] к каждому из методов, соответствующих моему интерфейсу.
Это хороший план атаки?
Если я выполняю этот план, я тогда декорирую класс атрибутом [ServiceBehavior ()], а затем каждый метод в классе атрибутом [OperationBehavior ()]? Мне вообще нужен атрибут OperationBehavior? Я почти уверен, что мне нужен атрибут ServiceBehavior.
Это будет более или менее соответствовать атрибутам ServiceContract и OperationContract на интерфейсе, верно?
Что делать, если у меня есть несколько перегруженных методов Execute_Query () и Execute_NonQuery () в оригинале (что я и делаю). Я знаю, как определить их в интерфейсе, используя параметр Name в атрибуте OperationContract:
[ServiceContract ()]
общедоступный интерфейс IData
{
[OperationContract (Name = "Execute_QueryA")]
int Execute_Query (список параметров ....); // список параметров здесь не должен быть важным, я надеюсь.
[OperationContract (Name = "Execute_NonQueryA")]
int Execute_NonQuery (список параметров ....);
[OperationContract (Name = "Execute_QueryB")]
int Execute_Query (список параметров ....); // список параметров здесь не должен быть важным, я надеюсь.
[OperationContract (Name = "Execute_NonQueryB")]
int Execute_NonQuery (список параметров ....);
}
Но что мне делать для фактической реализации? Должен ли я просто оставить [OperationBehavior ()] выполненным без изменений и не добавлять к нему какие-либо параметры? Кажется, нет имени параметра.
Буду признателен за любые мысли по этому поводу или ссылки на хорошие статьи, потому что я не нахожу много полезной информации, выходящей за рамки базового "Эй, я создал службу WCF с одним вызовом, размещенную в IIS ..."
Спасибо.