【问题标题】:Best architecture practice for multiple clients using one web service使用一个 Web 服务的多个客户端的最佳架构实践
【发布时间】:2010-10-14 02:52:59
【问题描述】:

我有一个 Web 服务和多个将使用它的客户端。 MVC 2.0 网站、winforms 应用程序和潜在的移动应用程序。

我了解,对于移动应用程序,每个应用程序都需要在内部访问和管理 Web 服务连接。但是对于 .net 应用程序我该怎么办?我对请求对象和返回类型使用复合类型。这是一个示例。

我最初的想法是有一个包装类来引用 Web 服务并且只是一个包装器。然后每个项目只需要调用我的包装类,并且只需要在 web config 中配置连接和凭据。

这是我的抽象请求。我拥有每个请求所需的所有共享属性。

[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 对象。我使用泛型是因为每个响应都是相同的,除了结果集的类型。

[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; }
}

问题在于,当我创建 Web 引用时,它会将我的服务接受/返回的类型转换为代理对象。

当我使用服务引用(而不是 Web 引用)时,它似乎工作得更好,但服务引用被暴露了,这不太理想。

我正在寻找可以减少代码重复的任何想法。

【问题讨论】:

    标签: .net architecture webservice-client


    【解决方案1】:

    不使用!使用 WCF 通过创建和缓存 ChannelFactory 连接到 Web 服务,然后每次创建一个代理。 WCF 是访问 Web 服务的理想选择。这样你就不需要任何参考了。

    【讨论】:

    • 我的 Web 服务是 WCF 应用程序。
    • 没关系。您的客户不必知道尽管两者都是 WCF 更好。所以我建议不要参考,只将你的接口暴露给你的客户端并创建通道工厂。
    • 这里的问题是每个项目都需要有服务契约的引用。如果我更改服务,我必须为每个客户端更新 DLL。
    • 您需要 - 始终 - 将您的服务合同(接口而不是实现)放在单独的程序集中并分发给您的客户。所以你的实现(类)将只驻留在服务器上,你可以用它做任何你想做的事情,并根据需要进行多次更改。
    猜你喜欢
    • 1970-01-01
    • 2011-04-27
    • 1970-01-01
    • 2018-04-14
    • 2020-08-15
    • 2013-01-17
    • 1970-01-01
    • 2020-11-11
    • 2012-05-24
    相关资源
    最近更新 更多