Super

组织：[EasyAbp](https://easyabp.io) 地点：GitHub 联系方式：[email protected] 使用场景：实现 Entity UI 模块动态生成 RazorPages 的表单模型；实现 Dynamic Entity 模块的（开发者可于运行时在线编写的）业务逻辑脚本

目前，配置注册机制主要用于对微信回调的签名认证，因此可以只以MchId->ApiKey进行存储。 * 建议在应用程序启动时，显式注册商户配置，具体的实现方式可能是：在`IWeChatPayOptionResolveContributor`增加获取所有配置的方法，在应用程序启动时，获取和遍历它们，进行注册。 * 并且提供运行时补充注册的方式，例如应用程序运行中新增了一个租户，它拥有一套独立的配置，则需要自动把它注册进去。 * 补充注册的方法可能导致在这套配置首次被使用之前，由于缺少配置，不能处理微信的回调，因此还是需要提供“运行时显式注册”的方法，对此有更高要求的开发者可以使用这个方法，在运行时对新增的配置进行显式注册。 * 在注册时难免碰到相同的MchId提供不同的ApiKey的情况，我们应该考虑每个MchId下存储多个ApiKey，在对微信回调进行签名认证时，从第一个ApiKey开始试用，碰到第一个正确的ApiKey，则将它移到第一位。 以上构想提供 @GameBelial 参考。

> 支付结果通知接口、退款通知接口，应在路由上传入AppId 已了解，微信调用回调地址时会传入appid参数。

> 所有的商户（AppId）应有注册机制 注册机制是为了提供足够信息进行签名验证，也可考虑设计成可替换的验证器

是否考虑使用setting，在全局、租户级别提供“商户配置”，并且允许开发者对此配置器进行重写或替换，从而实现更复杂场景？

可考虑： * 主动请求微信时：默认从setting中获取配置，支持手动临时覆盖默认配置 * 接收微信回调时：从商户注册表中读取配置，目前用于签名验证

> @gdlcf88 考虑使用单独的表存储，存储在 ISettingManager 限制很多，性能也有不少问题。 我们的框架模块最好不设计实体，保持轻量

What is the CAP Header in ABP for?

``` [20:09:06 DBG] Build started... [20:09:24 DBG] Build failed. Use dotnet build to see the errors. ``` Fix the code and run migration again.

Maybe this generation step is fine but not necessary. Since the `[Area(MyProjectRemoteServiceConsts.ModuleName)]` can be added to the [abstract controller class](https://github.com/abpframework/abp/blob/dev/templates/module/aspnet-core/src/MyCompanyName.MyProjectName.HttpApi/MyProjectNameController.cs). What do you think @wakuflair?