WCF один против нескольких операций? дизайнерские идеи

Question

Мы разрабатываем приложение CRM.Вся бизнес-логика и доступ к данным проходят через сервисы WCF.У нас есть 2 варианта связи между WCF и клиентом (на данный момент: ASP.NET MVC 2)

Один из вариантов - это метод create для каждой операции.Пример

    GetCustomers()
    GetCustomersWithPaging(int take, int skip)
    GetCustomersWithFilter(string filter)
    GetCustomersWithFilterPaging(string filter, int take, int skip)
    or // new .net 4 feature
    GetCustomers(string filter = null, int take = 0, int skip = 0)
     ... list goes..

Другим вариантом является создание общей отдельной сервисной операции с именем

Response InvokeMessage (Messege request) .Пример

wcfservice.InvokeMessage(
   new CustomerRequest { 
       Filter = "google", 
       Paging = new Page { take = 20, skip = 5}
   });

// Service Implementation.
public Response InvokeMessage(Message request) 
{
     return request.InvokeMessage();
}

InvokeMessage = общий одиночный сервисный вызов для всех операций.

CustomerRequest = Унаследованный класс от Сообщение абстрактный класс, поэтому я могу создавать несколько классов из базового класса сообщений в зависимости от требований ввода.Вот класс CustomerRequest.

 public class CustomerRequest : Message
 { 
   public string Filter {get;set;}
   public Page Paging {get;set} // Paging class not shown here.
   Public override Response InvokeMessage() 
   {
       // business logic and data access
   }
 } 

EDIT

public abstract class Message
{
    public abstract Response InvokeMessage();
}

// все вызовы службы будут выполняться только через метод InvokeMessage, но с другими запросами сообщений.

По сути, я мог бы избежать закрытия каждого вызова службы и прокси-сервера и т. Д. Одним из непосредственных последствий этого подхода является то, что я не могу использовать эту службу как REST

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

спасибо.

Answer 1

Если вы используете шаблон фасада, у вас может быть и то и другое.

Сначала создайте свои сервисы, используя первый вариант.Это позволяет вам иметь интерфейс REST.При необходимости это можно использовать внешне.

Затем можно создать фасад, который использует стиль сообщения Invoke, который транслирует запрос на основе параметров и вызывает одну из отдельных служб, созданных на первом шаге.

Answer 2

Что касается вопроса о нескольких конкретных операциях по сравнению с одним общим запросом - любой подход может быть допустимым; определение мелкозернистых по сравнению с крупнозернистыми операциями является в некоторой степени вопросом вкуса.

Столкнувшись с аналогичным требованием в нашем сервисе RESTful, я решил создать класс фильтра, который считывает параметры из строки запроса, доступные следующим образом:

public NameValueCollection ReadQuerystring()
{
    return WebOperationContext.Current.IncomingRequest.UriTemplateMatch.QueryParameters;
}

Большая проблема, которую я вижу здесь, заключается в том, что вы создаете подклассы Message для своих параметров работы - есть ли причина, по которой вы это делаете? Для этой цели рекомендуется создавать контракты данных (объекты, помеченные атрибутами [DataContract]).