依赖注入容器可否替换成自带容器或可自定义
Opened this issue · 17 comments
这一块不是很容易实现它，因为我没有对依赖注入容器本身设计抽象接口来实现依赖倒置，在代码里大量使用了autofac的具体实现(比如ilifetimescope)。如果你有兴趣，可以fork分支单独设计依赖注入的抽象从而实现容器的可替换性
能接入这个https://www.dtm.pub/ 分布式事务框架吗?
理论上是可行的哈，dapr本身并不涉及分布式事务，所以你完全可以在应用层独立的引入第三方框架来实现分布式事务，不冲突的
升1.9了吧
着什么急，以微软的尿性，一般在小版本号才会稳定。等1.9.1或者1.9.2这种热修补出来再说
1.9.4,现在稳吗，是不是用你这个actor就不用锁了
actor和分布式锁使用场景都不同啊，actor是单个实体实现了原子性。当然理论上你也可以用actor的实体来实现一把分布式锁哈。但是锁的作用主要还是在分布式系统中去确保多线程操作相同资源的一致性。这个资源不一定是actor，有可能是其他数据，对象，甚至过程。
哦，现在用的是redis加上数据id做key
https://github.com/Cysharp/MemoryPack 新出的这个和Newtonsoft.Json，.net6的json哪个好些
这和dapr有啥关系。。。序列化/反序列化在分布式系统里不是性能瓶颈
来回传输啊，A端调B端
这个我知道，我意思讨论这个的意义不是很大，现在的text.json序列化就足够快了，没必要搞三方的。除非特殊场景确实对性能有极致要求。一般的分布式系统你的业务瓶颈产生的延迟相比这点优化都不够塞牙缝的。
https://www.cnblogs.com/qwqwQAQ/p/16944672.html 嗯，看这个text.json是原生的吧，很慢，比Newtonsoft.Json还慢
微软官方有标准的benchmark验证过的system.text.json是远快于Newtonsoft的，这个没必要看这些三方的博客去质疑官方的数据。
我看你用的是MessagePack，但和官网用法不一样，实体类上没用MessagePackObject特性
应该是以前我做过一套纯RPC框架，后面搞dapr就迁移了一部分代码遗留的，理论上dapr走http其实.net自带的kestrel+text.json就足够了。另外mp不需要打特性标签，当时看过protobuf和mp，前者要求加特性后者不需要，所以选了后者。
嗯，对外部前端只能json,内部调用用mp