对 PR #29 的讨论

[John0King]

对于 PR #29 的讨论

讨论的方面：

1. 关于 DI 方面的处理
2. Logging 日志的处理
3. PaySharp.AspNetCore 命名 （改变 Target 还是 改变支付 实现的名字）
   方案1： 将 Target 挪到独立的命名空间下， 如 PaySharp.Target.* (PaySharp.Target.AspNetCore)
   方案2： 将 支付机构的实现挪到独立的命名空间下， 如 PaySharp.Authorities.* (PaySharp.Authorities.Alipay)
4. 处理支付时的优化， 最好我们可以使用同一个处理类或函数 处理不同的 支付机构的 响应 。

[John0King]

@Varorbc 我写的那个 IGatewayProvider 感觉还是不行， 每回在你请求 IGatewayProvider 的时候 都会实例化所有的 gateway 👎
感觉最后还是得 利用 ServiceProvider 才行 ， 或者使用 lazy<T>

[Varorbc]

感觉还是用lazy吧，你觉得呢？

[John0King]

为了支持 多租户 或者 多支付配置， 现在的想法是：

1. IPaySharpBuilder 用来添加 Service 或 IPaySharpOption
2. IPaySharpProvider 来统一获取 Service 和 IPaySharpOption

IPaySharpProvider 扩展方法必须实现 Factory方法 比如：Extensions.CreateAlipayClient(this IPaySharpProvider provider,IPaysharpOption option)

另外将 支付的组件抽象为：Client 和 Listener 。Client 用来 发起支付的一些请求（支付/退款 等, 建议采用动词分别发起，如：PayAsync, CancelAsync, RefundAsync），Listener 用来监听支付机构的通知44

这样的好处

1. 扩展性提高， 因为各个支付的 Client 和 Listener 不需要相同的行为，其他人更容易对 PaySharp 的基础结构进行扩展
2. 采用 动词做方法明确，传递的参数可以更明确，更好理解。

丢失的功能

1. 单点多支付监听 ， 理论上可以抽象一个 IListenerValidator 之类的总就是 采用注入的方式 添加一个 参数验证器，并返回 Listener 实例以及 IPaysharpOption , （因为 Listener 不同， 返回的本身就应该就是执行器 )

[viewtance]

多租户功能支持了吗？

[Varorbc]

@viewtance 一直是支持的