We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
1.一个业务只能有一个拓展点 2.拓展点的锚定比较死,比如说我一个业务B可能有一个拓展点处理一些特殊参数,然后针对该业务订单金额大于某个值还有一个拓展点需要做一些校验或参数处理,拓展点好像无法实现 如果是传统的策略模式,我用一个support方法去找实现类,support里的条件我可以各种自定义,也可以找到多个实现类循环执行 所以没太理解这个拓展点到底好在什么地方
The text was updated successfully, but these errors were encountered:
这个extension机制源自于阿里的中台设计思想,本质上就是策略模式
Sorry, something went wrong.
一个业务怎么可能有一个拓展点,肯定是N个,这个扩展点的实现和判断条件肯定是配置在分布式配置文件里面随时修改和读取的,不同的一个业务不同的数据匹配不同的扩展点实现
可以基于拓展点再进行包装,Dubbo的StubProxyFactoryWrapper就是这样用的,AOP。
一个业务怎么可能有一个拓展点,肯定是N个,这个扩展点的实现和判断条件肯定是配置在分布式配置文件里面随时修改和读取的,不同的一个业务不同的数据匹配不同的扩展点实现 可以基于拓展点再进行包装,Dubbo的StubProxyFactoryWrapper就是这样用的,AOP。
No branches or pull requests
1.一个业务只能有一个拓展点
2.拓展点的锚定比较死,比如说我一个业务B可能有一个拓展点处理一些特殊参数,然后针对该业务订单金额大于某个值还有一个拓展点需要做一些校验或参数处理,拓展点好像无法实现
如果是传统的策略模式,我用一个support方法去找实现类,support里的条件我可以各种自定义,也可以找到多个实现类循环执行
所以没太理解这个拓展点到底好在什么地方
The text was updated successfully, but these errors were encountered: