本文版权归博客园和作者吴双本人共同所有 转载和爬虫请注明原文地址 www.cnblogs.com/tdws
C#本地实现的和Redis Set实现的，实际上都是要维护一个Events和Handlers的对应关系，sub建立关系（也可以称为Regist）, pub用户查询存在哪些关系，并调用。这些都是非分布式的情况，可以当你有一台应用服务器的时候用C#字典实现对应关系的存储就可以。当同一个应用做负载均衡于多台服务器上，为保证发布订阅的对应关系，在各台服务器上保持一致，这个时候可使用Redis 作为一个对应关系存储者。当然如果你确保，pub/sub关系，在程序一开始建立以后，不会被动态改变，那么前两者均可。
如果需要分布式处理，发布者和订阅者或者说生产者和消费者分离，那使用MQ和Redis的pub/sub是最合适不过的。
在将来的拓展中，只需要定义事件对象，事件处理器和维护他们之间的关系。
也听过这样的说法，在项目伊始，很多设计是增加了代码的复杂程度，应该一切从简，以流畅开发为主。曾在一定程度上，我认为这样的说法是有道理的，项目开始和搭建的过程中，的确要摒弃照猫画虎的行为，不是架子漂亮就合适。但是在面对项目日益增加的需求，随之带来的逻辑上的复杂度增加，极简的框架的确承受不来，我见过的几个项目存在这样的问题，极简的几层=>日益庞大的逻辑层，混杂sql的逻辑，几个甚至十几个接口公用同一个Model。
当然这不是在抱怨，这几个项目我也没在写后端的逻辑，我也不认为我一定能比谁写得好，只是做个反思，项目的任何问题，都是整个团队的问题。
在过去前两年的学习中，自己“照虎画猫”搭架子，先建几层接口，再用几层实现，不管懂不懂搞个依赖注入，工厂就算面向接口了，再来个EF仓储，工作单元，加上些遍布在代码中到处都是的缓存这就是持久了，对了再搞个Restful风格的Api,给分页弄个PageResult啥的等等，
想想面对复杂和日益增加的需求，终究是经不住什么考验，把太多的时间花在怎么搭的漂亮，而从不考虑业务上如何抽象和组合，上面是比较主观的一些反省。
想想面对复杂和日益增加的需求，终究是经不住什么考验，把太多的时间花在怎么搭的漂亮，而从不考虑业务上如何抽象和组合，上面是比较主观的一些反省。
更让我现在觉得不对劲的是，当初在学校 学习面向接口的时候，有些资料解释其好处，这样说道：“如果以后你换一个Dal层 或者你换一个service层，把这套接口重新实现一下，其他逻辑不用动。” ， 现在想想，这说的是shit？谁会把一套service或者dal换掉？举个恰当的栗子好吗，让人产生误解影响深远。倒不如说，你有个IRedisClient接口，提供了两套实现，一套RedisClient和一套RedisClusterClient， 你可以在单节点和集群间灵活切换。否则给别人一种 面向接口没什么意义的感觉。补充一点，从面向服务的角度，Service面向接口编程，是将来做RPC调用最基本的支撑，所以service需要你的IService，在服务提供者和服务消费者之间做好规范。
客观的来看，学习的路上走弯路也算是少不了的过程，还要继续画下去，但更多的应该让自己关注在解决什么问题上，而不只是画的漂亮，多读书，多实践，不知不言，言则有据，把握本质，正确运用。
接触过很多做C#的朋友，也有很多做Java的朋友。C#方面开发大多关注代码层面的框架，假如他们不关注代码层面的框架，面对日益复杂的需求，得到的结果就是严重耦合，难以拓展，写到最后就是一堆面向过程的逻辑代码，也没有什么出名的框架从Web层到服务，再到数据层整合的比较完善，在分布式方面的设计和解决方案还有待普及。 C#方向的童鞋研究DDD的有很多，能研究一些这样思想的，比抱着“三层”架构写臃肿的代码的朋友强的多得多，至少人家有一颗将复杂业务简单化的心。还有.net架构设计实战此类的国产书，纠结讨论于BeginTranscation()到底能不能写在逻辑层中，如果写在数据层，又要掺杂了很多业务逻辑怎么办，难免让人无力吐槽。
而Java方面，代码层面的框架关注度可能少一点，在整个架构体系，从代码层面的解耦到服务层面的解耦，拓展性方面会关注度会高一些，并且基本web项目都得益于Spring框架，各种解决方案比较完善，比如单体架构拆分成SOA。