EventBus的思路和一些反思

2018-06-22 07:31:24来源:未知 阅读 ()

新老客户大回馈,云服务器低至5折

本文版权归博客园和作者吴双本人共同所有 转载和爬虫请注明原文地址 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。
 
 
 
 

 

 

标签:

版权申明:本站文章部分自网络,如有侵权,请联系:west999com@outlook.com
特别注意:本站所有转载文章言论不代表本站观点,本站所提供的摄影照片,插画,设计作品,如需使用,请与原作者联系,版权归原作者所有

上一篇:CYQ.Data V5 分布式自动化缓存设计介绍

下一篇:Asp.Net 高性能ORM框架 SqlSugar.ORM 2.8