public interface ICommand
    {
        object parameter { get; set; }
        object Execute();
    }

    public abstract class Command<T, S> : ICommand
    {
        public abstract S Execute(T parameter);

        public object Execute()
        {
            return Execute((T)parameter);
        }

        public object parameter{get;set;}
    }

------解决方案--------------------
我喜欢直接用ASP.Net HTTP Handler，轻量，我往.ashx这样的一个地址POST一个request class的json字符串，再接收一个response class的json序列化后的字符串，再反序列化得到response的内容。其实这就是个轻量级的service。


------解决方案--------------------
使用socket，特别是使用长连接异步处理，你会发现要比http通讯快许多倍，特别是输入参数和返回对象是比较复杂的自定义类型时。比WCF快多少倍我都懒的去比较了。

当然长连接异步异步处理在最基本的信令设计上要稍微复杂一点。简单说一下长连接：


例如这样的格式（序列号为ulong类型）：
    
      命令类型|发送端会话id|接收端会话id|序列号|json

这样当服务器端刚刚解析到“接收端会话id”不是自己时，就简单地发消息发送给对应的客户端就行了。而当消息确实是发送给自己的，它异步地执行json，然后将返回结果以格式
        返回数据类型|服务器端id|客户端id|-序列号|json的格式返回。

比如说客户端与服务器端建立了连接之后，它可能按照次序1、2、3、4、5的次序发送了5命令，然后异步地以3、5、2、1、4的次序收到了返回结果（因为服务器端是异步执行这些命令的，这些命令所用时间长短不同，所以返回的次序不定），那么客户端需要一个异步机制，在收到命令返回时才去回调相应的命令的下一步处理程序。

------解决方案--------------------
"...（一直做bs开发，理解的不对请无视）：..."有很好的基础耶，我们就拿browser和webserver来讨论。

browser和webserver之间的通讯也是SOCKET通讯，应用层使用HTTP协议（HTTP协议是基于TCP的，文本的），简单点你可以这样理解：browser向webserver发送字符串，一般80端口，TCP/IP通讯，webserver收到消息后给browser应答，然后挂机不里你了。深入点你研究下HTTP协议，用FIREFOX浏览器安装HTTP插件观察下GET、POST、RESPONSE时的内容。  

OK，然后我们来说你的“CS架构”。其实，前面那段 browser和webserver之间的通讯 就是“CS架构”。他和你这里要求的“CS架构”差别在于BS传输时使用了HTTP协议，而你的DEMO想用你自创的武功。
说句废话，绝顶的高手们（注意们字）创建功夫流派，真正高手喜欢使用某流派，一般人喜欢使用自创的流派。

怎么个自创法呢，TCP通讯，服务器在某个端口侦听外面的电话（把客户端比喻成电话），你拨通了服务热线，服务器就建立了一条通信的管道（SOCKET）为您服务，他自己则继续侦听。。。你在热线中的通话，可以自由地和接线员打情骂俏，发送图片、病毒、EXE等都可以（一切数据皆文件或者01010101，这个不用我再说了吧），只要这些内容遵循你自创的协议。TCP保证你们的通信是传输内容正确、顺序正确的。当前通话怎样挂机呢，3种情况：1、我拍拍屁股挂了；2、受不了你的骚扰对方把你挂了；3、电话线被人断了。BS是接了电话，根据你的请求，发个回应就马上把你挂了。你认为这样比BS爽多了吗？其实不然，维护这么条通信管道太昂贵了，这个话费我吃不消。另外，分机号如果不是80端口也很难拨通（路由器、防火墙。。。），所以在大规模的系统中我不喜欢这样的模式（个人喜好）。
另外，
UI→Controller（client端）→socket共通类（arg1:指令类型,arg2[]:参数列表））→（遵循HTTP协议的字符串）→Socket通信→Controller？（server端））→（遵循HTTP协议的字符串）→[→BLL（Action，不知道有没有这一层）]→DAL（service）→DB Server