CQRS中跑在总线上那些小类型小对象啊
一直有个纠结的问题是Anycmd权限引擎中有大量的小类,Command和Event类 和Input、Output类都是小类。这些小类的唯一作用只是在总线上传递的数据的载体。很想把这些小类都去除然后使用Dictionary<string, object>去取代。但是不知道这两种方式到底哪个更好管理?哪个效率更高?这些具体的Command和Event .NET类型数据可以用来对消息(包括Command和Event)进行分类(class的本质是对人类使用了上万年的古老分类法的应用,分类的是运行时对象),然后在总线上可以通过这种基于.NET类型的分类来路由它们,基于.NET类型来登记消息类型,发布、订阅消息。
考虑是否让承载数据的小类型回老家? 然而我在Dictionary<string, Object>字典中添加个key为“MessageSubject”的项一样可以啊。而且Subject才是个更准确的词汇,对于Event来说,发布订阅时使用的词汇是Subject而不是.NET类型。
如果使用Dictionary<string, Object>取代.NET类型的话我们可以把Dictionary<string, Object>的Key提取出来持久化到数据库管理。
Anycmd权限引擎的额外收获
.NET版本的Anycmd写完后我大致明白如何把它投射成java、nodejs、golang、rust等多种版本了,不只能做到接口层使用起来是一样的,甚至能做到源代码都是相似的。
希望减少人们以后在系统的访问控制方面的纠结。anycmd设计的足够抽象,也会编码到拿来即可使用的地步,理想是人们在开发业务系统的时候再也不用书写任何访问控制逻辑,只需在上线运行前安装上权限引擎驱动的一个防护罩就万事Ok了。
具体信息系统防护罩
可以取个名字叫“具体信息系统防护罩”。
权限引擎是永远开源免费的,如果你针对某个具体业务领域配置权限引擎,你配置出那个具体领域的资源、功能、角色等数据,你初始化权限引擎,你推出的“某某信息系统防护罩”可以收费。
权限引擎官方不参与上层建设 权限引擎是底层事物,上层会有很多可能付费获得的事物:比如权限引擎管理系统(类似那个AnycmdMisSite项目,不由anycmd官方提供,任何人可以提供)、比如管理系统的UI框架、比如将权限引擎应用到具体的业务系统(帮助配置、开发)……所有的这些业务都不是官方提供的,任何人可以提供。
官方只负责构建权限引擎,如果官方提供买卖平台的话,官方只靠5%-8%的服务费维持。
困难
我搜寻过可靠权限系统设计者的言论,他们从来没有说过“业务权限”神话不可打破,只是说实现起来有困难。
一定需要这样理解,不这样理解的话整个世界就复杂了,而这样理解才能让世界清静。 理解为由主体携带这些数据在隧道中穿梭,而不是主体被携带。只有主体具有能动性。
主体来到整个系统(一棵树)的某些节点,主体将某些节点连接起来,主体在树上构建局部的通路,主体监管通路中的运动,主体再选择在回路的何处(空间)断开回路再次回到树形。 这个过程是主体变换那棵树的过程,只有主体能够变换那棵树,它自己不能变换。
######我去,QQ搞的图标
版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。