化茧成蝶，开源NetWorkSocket通讯组件

前后历时三年，期间大量参考.Net Framework和Asp.net MVC源代码，写写删删再重构，组件如今更新到V1.5.x了。从原来的丑小鸭，变成今天拥有稳定和强大的tcp协议支持基础层，原生支持http、websocket、flash策略服务，以及内置可快速构建tcp通讯的fast协议，最重要的是可基于此组件，很方便开发自己定义的某种tcp上层协议服务器和客户端。如果有人以支持的功能多为荣，我却以支持的扩展性强为傲，从WebForm到MVC的 时候，被其可依赖注入、可Filter过滤器拦截、Modelbinding及反射执行Action等新颖的思想震撼了！现在很高兴在这个组件里也模仿和使用了这些思想。

组件的功能

1、tcp服务器抽象类和客户端抽象类，以及相关的流读写功能类，字节和位操作等功能类。所有基于tcp的标准协议和个人自定义协议的服务都基于此继承来开发，抽象类已实现很多最基础功能。

2、内置flash和silverlight策略服务类，支持继承重写部分功能。

3、内置http服务模块，编写http服务时风格习惯与Asp.Net MVC极其一致，只差不支持视图。

4、内置websocket服务模块，同时封装基于json的jsonWebsocket服务和客户端脚本，从IE6到Chrome的web双工通讯不再是梦，编写jsonWebsocket服务时风格习惯和MVC一致。

5、内置名为fast的自定义个人协议，开发.Net内部使用的系统，可无视通讯知识就能编写tcp双工服务，编写服务风格习惯和MVC一致，客户端不需额外编写。

6、内置也能在EF下使用的Model验证特性，编写各种服务时，Model验证不在是恶心的一坨占了半个函数的if。

7、功能强大的Filter，AOP思想可以在http、jsonWebsocket、fast服务编写时大显身手，淋漓尽致，日志、异常和权限验证变得如此简单。

8、依赖注入支持，可以替换默认的依赖解析提供着，比如使用Autofac等优秀的依赖注入提供者来减少耦合或生命周期管理，Filter也支持依赖注入。

框架理念

我觉得有时自己在tcp这块博客的相关看法和评论比较暴躁，有时想指责或找出别人的不足来突显自己在这领域一样，这个非常不好，但很多时应该还是比较平心气和的。但我比较反感问我这个和其他一些思想理念不一样的相关组件的比较结果，每个框架都有自己的理念，有些是不能比的，或比不出结果，就像MVC和MVVM，我说都好，我希望想用的人自己先理解，然后结合自己的需求，比较选择。我的理念是构建一个稳定的基础层，支持一些标准协议，可以带但不能只拘泥和局限于某种自定义协议（比如组件里的fast协议）。如果组件从头到尾都是一个自定义的协议，那它应该是一把专用钥匙，离开了这个锁就是废铁（如果协议推广很广泛了另说）。当然万能钥匙是不存在，但是当锁是别人的，看到了之后，能通过这个组件低成本把相应的钥匙给造出来，这便是我的理念。

组件的移植

组件不依赖于任何第三方库，目的是保证体积小，同时移植方便。默认实现的序列化在移植时可替换。

1、Mono编译不用修改任何代码；

2、.Net core移植想要修改少量代码，但不会影响到逻辑的修改，只是序列化相关的代码。

组件适用范围

如果你用过MVC，那么使用本组件你可以轻易地实现以下需求：

1、在所有常见的浏览器里实现双工通讯比如及时通知和及时聊天等，从此再也不觉得老板想在web中实现推送不是变态。

2、.Net下双工通讯项目，比wcf更简单，无需关注通讯知识。

3、混合协议中转服务，你可以构建一个支持多协议的服务，比如浏览器端使用http和websocket，手机端使用http，其他硬件使用一些自定义tcp协议，达到多端控制硬件的目的。

4、编写一些客户端，或一些其他服务，比如redis等的.Net驱动，或telnet服务器，或其他你自定义的协议。

后记

今年来写的博客很多都是这个组件里面的某一角，有些甚至看似没关系的一样，但都是组件里背后默默工作的对象。从没有这样完整简述过组件的面貌，因为觉得时期还未到，在设计Filter的时候，曾经完全模仿MVC4的Filter，由于不同协议的上下文不同，每个协议都得写貌合神离的Filter，就像MVC与WebApi的过滤器一样，相似却不一样，后来重构的时候，否定了原来这种Filter设计思想，开发一套通用的Filter基础，虽然模仿了也借鉴了，但如果不适合，也要敢于否定。篇幅有限，寥寥一文，无以提及所有方面，故捡几重要点贴于斯文。