Лучшая практика архитектуры для нескольких клиентов, использующих один веб-сервис

У меня есть веб-служба и несколько клиентов, которые будут ее использовать. Веб-сайт MVC 2.0, приложение winforms и, возможно, мобильные приложения.

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

Моя первоначальная мысль состояла в том, чтобы иметь класс-оболочку, который бы ссылался на веб-службу и был бы просто оболочкой. Затем каждому проекту просто нужно вызвать мой класс-оболочку, а соединение и учетные данные нужно будет просто настроить в веб-конфигурации.

Это мой абстрактный запрос. У меня есть все общие свойства, которые понадобятся каждому запросу.

[DataContract]
    public abstract class RequestBase : IRequest
    {
        #region IRequest Members

        [DataMember]
        public string ApiKey { get; set; }

        [DataMember]
        public string ApiPassword { get; set; }

        [DataMember]
        public int PageSize { get; set; }

        [DataMember]
        public int PageIndex { get; set; }

        #endregion

        public RequestBase() : this(String.Empty, String.Empty) { }

        public RequestBase(string apiKey, string apiPassword)
        {
            ApiKey = apiKey;
            ApiPassword = apiPassword;
        }
    }

Тогда вот класс, который наследуется от моего базового класса.

[DataContract]
    public class CustomerRequest : RequestBase
    {
        [DataMember]
        public int Id { get; set; }
    }

И вот мой объект Response. Я использую Generics, потому что все ответы одинаковы, за исключением типа набора результатов.

[Serializable]
public class Response<T>
{
    public IEnumerable<T> Results { get; set; }
    public int TotalResults { get; set; }
    public int PageIndex { get; set; }
    public int PageSize { get; set; }
    public RulesException Exception { get; set; }
}

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

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

Я ищу любые идеи, которые уменьшат дублирование кода.


.net architecture webservice-client
person Josh    schedule 13.10.2010    source источник

Ответы (1)


arrow_upward
1
arrow_downward

Не используйте ни одного! Используйте WCF для подключения к веб-службе, создавая и кэшируя ChannelFactory, а затем каждый раз создавая прокси. WCF идеально подходит для доступа к веб-службам. Таким образом, вам не нужна никакая ссылка.

person Aliostad    schedule 13.10.2010
comment
Мой веб-сервис - это приложение WCF. - person Josh; 13.10.2010
comment
Не имеет значения. Вашему клиенту не обязательно знать, что лучше оба WCF. Поэтому я предлагаю не ссылаться, а только предоставить ваш интерфейс вашему клиенту и создать фабрику каналов. - person Aliostad; 13.10.2010
comment
Проблема в том, что каждый проект должен иметь ссылку на сервисный контракт. Если я меняю службу, мне приходится обновлять DLL для каждого клиента. - person Josh; 13.10.2010
comment
Вам нужно всегда помещать свой сервисный контракт (интерфейс, а не реализацию) в отдельную сборку и распространять среди своих клиентов. Таким образом, ваша реализация (класс) будет находиться только на сервере, и вы можете делать с ней все, что хотите, и изменять ее столько раз, сколько хотите. - person Aliostad; 13.10.2010