Должны ли компоненты веб-службы WCF быть связаны с сетью?

Question

Я узнаю о веб-службах WCF и обеспокоен всеми связями, которые вижу. На мой взгляд, я должен быть в состоянии написать компонент и затем использовать его где угодно - внутри процесса, через интрасеть или со страницы ASP.NET, и нужно всего лишь изменить способ его размещения.

Как только вы начинаете работать с System.ServiceModel.Web, вы начинаете украшать свои ServiceOperations такими вещами, как:

[OperationContract]
[WebGet]
string EchoWithGet(string s);

Правильно, связь метода с сетью. Можете ли вы использовать подобный контракт в сервисе, который будет размещен в proc?

И в некоторых примерах, которые я смотрю, я также вижу код:

public class FavoriteMovieService : IFavoriteMovie
{
  MyFavoriteMovie item = new MyFavoriteMovie();

  public MyFavoriteMovie GetItem()
  {
    if(item == null)
      throw new WebProtocolException(HttpStatusCode.NotFound, "Not found.", null);
    return item;
  }
}

Вы бы не хотели создавать исключение, подобное этому, в коде вашего сервиса, если вы размещали in-proc, верно ??

Есть ли еще хорошие способы написания веб-сервисов WCF, и, надеюсь, RESTful, которые не требуют такой тесной связи с сетью? Кажется, что победить всю цель WCF.

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

Пожалуйста, просветите меня. :)

Answer 1

Да, вы можете использовать этот контракт с конечной точкой вне сети. Он будет использовать команды RESTful, только если вы используете конечную точку, которая распознает это (WebHttpBinding с .NET 3.5 sp1). В противном случае он будет вести себя как любой другой контракт с данными. Если вы используете именованные каналы, все будет нормально в процессе. Кроме того, использование привязки WebHTTP полностью уничтожит способность любых других конечных точек на вашем узле обслуживания предоставлять метаданные. Если вам нужно сделать это, вы должны создать два отдельных сервис-хоста. Один для сервиса RESTful, а другой для всего остального. Это была пара часов отладки.

Что касается ошибки, то это немного надуманный пример. Я позволил бы WCF обрабатывать все ошибки уровня связи и выбрасывать только те ошибки, которые вы можете обработать на другой конечной точке. В противном случае, верните сообщение с каким-то кодом ошибки, который фактически может обработать ваша другая конечная точка. Кроме того, до тех пор, пока исключение оставляет ваш объект в непротиворечивом состоянии, просто съешьте его и не ошибайтесь в канале.

В связанной заметке я обнаружил, что проще создать объект распознавателя интерфейса для вызовов inproc. Он ведет себя (в основном) как servicehost, за исключением того, что мне не нужен клиент, я могу попросить объект разрешить интерфейс для меня. Издержки WCF немного велики для вызовов inproc.