在3.5下实现无配置WCF服务

    WCF在不断的进步，在4.0下可以很简单的实现无配置WCF，从此不再为哪大段大段的配置而感到头痛了。

    但是，现实是残酷的，项目的.net框架版本不是说变就变的。不过，对于会写代码的人来说，总有办法能绕过这些杂七杂八的麻烦事情。

    之前的一片文章中已经写了无配置客户端如何实现，但是里面的服务端还是需要配置的，这样还是有少许的不便。所以，今天再来一个完全不用配置文件的WCF测试全套方案不漏——WCF无配置Service端（3.5框架）

    首先，来想一下，WCF需要配置的罪魁祸首是谁？微软，呵呵，确实没错，但是，再具体一点——ServiceHost类。

    就是它要去读取配置，所以，要想实现无配置的WCF服务端，必须从这个类开刀。于是需要修改一下这个类型的某些行为：

    public class SimpleServiceHost
        : ServiceHost
    {

        public Uri Uri { get; set; }
        public Binding Binding { get; private set; }

        public SimpleServiceHost(Type serviceType,
            Binding binding, Uri uri)
        {
            if (uri == null)
                throw new ArgumentNullException("uri");
            if (binding == null)
                throw new ArgumentNullException("binding");
            Uri = uri;
            Binding = binding;
            InitializeDescription(serviceType, new UriSchemeKeyedCollection(uri));
        }

        public SimpleServiceHost(object singletonInstance,
            Binding binding, Uri uri)
        {
            if (singletonInstance == null)
                throw new ArgumentNullException("singletonInstance");
            if (uri == null)
                throw new ArgumentNullException("uri");
            if (binding == null)
                throw new ArgumentNullException("binding");
            Uri = uri;
            Binding = binding;
            InitializeDescription(singletonInstance, new UriSchemeKeyedCollection(uri));
        }

        protected override ServiceDescription CreateDescription(
            out IDictionary<string, ContractDescription> implementedContracts)
        {
            var result = base.CreateDescription(out implementedContracts);
            foreach (var contract in implementedContracts.Values)
            {
                var endpoint = new ServiceEndpoint(contract, Binding, new EndpointAddress(Uri.ToString()));
                endpoint.Name = Binding.Name + "_" + contract.Name;
                result.Endpoints.Add(endpoint);
            }
            return result;
        }

    }

    这个SimpleServiceHost直接继承ServiceHost，然后修改了CreateDescription方法，为契约们增加终结点。

    看到这里，一定会想然后哪？

    不幸的是，这些就是全部的代码了，后面的都是测试代码了，是不是感觉太简单了，就像被忽悠了。是不是被忽悠就直接看测试吧（别忘了上一片文章里面的两个扩展方法）：

[TestMethod]
public void TestHelloService()
{
    var uri = new Uri("net.tcp://127.0.0.1:2323/Console/");
    var binding = new NetTcpBinding();
    new SimpleServiceHost(typeof(HelloService), binding, uri).RunWcfService(
        () => uri.InvokeWcfClient<IHelloService>(binding,
            c => Assert.AreEqual("Hello world!", c.Hello("world"))));
}

[ServiceContract]
public interface IHelloService
{
    [OperationContract]
    string Hello(string name);
}

public class HelloService
    : IHelloService
{
    public string Hello(string name)
    {
        return "Hello " + name + "!";
    }
}

    只要这些测试代码，我们的测试就可以跑了。

    如果是实现类实现了多个服务契约会怎么样哪？

[TestMethod]
public void TestMultiService()
{
    var uri = new Uri("net.tcp://127.0.0.1:2323/Multi/");
    var binding = new NetTcpBinding();
    new SimpleServiceHost(typeof(MultiService), binding, uri).RunWcfService(
        () =>
        {
            uri.InvokeWcfClient<IHelloService>(binding,
                c => Assert.AreEqual("Hello world!", c.Hello("world")));
            uri.InvokeWcfClient<IEchoService>(binding,
                c => Assert.AreEqual("abc", c.Echo("abc")));
        });
}

[ServiceContract]
public interface IEchoService
{
    [OperationContract]
    string Echo(string message);
}

public class MultiService
    : IHelloService, IEchoService
{
    public string Hello(string name)
    {
        return "Hello " + name + "!";
    }

    public string Echo(string message)
    {
        return message;
    }
}

     IHelloService的契约不变，再加个IEchoService，在测试用例中同时测试这两个客户端，可以发现依然正常。

    有了这个类，在单元测试中，就完全可以抛弃WCF的配置文件（正式的运行环境通常还是需要配置在灵活性方面的优势）。