基于SqlSugar的开发框架循序渐进介绍(23)-- Winform端管理系统中平滑增加对Web API对接的需求

简介: 基于SqlSugar的开发框架循序渐进介绍(23)-- Winform端管理系统中平滑增加对Web API对接的需求

在前面随笔介绍的基于SqlSugar的WInform端管理系统中,数据提供者是直接访问数据库的方式,不过窗体界面调用数据接口获取数据的时候,我们传递的是标准的接口,因此可扩展性比较好。我曾经在随笔《基于SqlSugar的开发框架循序渐进介绍(5)-- 在服务层使用接口注入方式实现IOC控制反转》中介绍过,该SqlSugar开发框架本身是基于IOC控制反转的,因此对于接入不同的数据提供者,只需要切换到对应的实现层上即可。本篇随笔介绍基于SqlSugar开发框架的Winform端,实现包括对直接访问数据库,远程调用Web API接口的两种不同的处理方式的整合。

1、Winform模块中对具体接口的调用及接口注册

Winform中的界面展示,以及数据处理,都需要具体实现的支撑,由于本身IOC控制反转的接口设计,我们对具体数据的访问,也是基于特定的接口层进行调用的,具体的实现,则是在程序启动的时候,注入对应的接口实现即可。

例如对于客户信息的展示业务操作,代码如下所示

/// <summary>
/// 数据显示的函数
/// </summary>
public async override void DisplayData()
{
    if (!string.IsNullOrEmpty(ID))
    {
        #region 显示信息
        var info = await BLLFactory<ICustomerService>.Instance.GetAsync(ID);
        if (info != null)
        {
            tempInfo = info;//重新给临时对象赋值,使之指向存在的记录对象        
            txtName.Text = info.Name;
            txtAge.Value = info.Age;
        } 
        #endregion
        //this.btnOK.Enabled = HasFunction("Customer/Edit");      
    }
    else
    {
        //this.btnOK.Enabled = HasFunction("Customer/Add");  
    }              
}

上面代码可以看到,我们是调用接口进行数据的处理的,而这个接口就是在程序启动之处,通过自动的方式获得对应的接口和实现类,然后进行注入的。

.net 中 负责依赖注入和控制反转的核心组件有两个:IServiceCollection和IServiceProvider。其中,IServiceCollection负责注册,IServiceProvider负责提供实例。

在注册接口和类时,IServiceCollection提供了三种注册方法,如下所示:

1、services.AddTransient<IDictDataService, DictDataService>();  // 瞬时生命周期
2、services.AddScoped<IDictDataService, DictDataService>();     // 域生命周期
3、services.AddSingleton<IDictDataService, DictDataService>();  // 全局单例生命周期

如果使用AddTransient方法注册,IServiceProvider每次都会通过GetService方法创建一个新的实例;

如果使用AddScoped方法注册, 在同一个域(Scope)内,IServiceProvider每次都会通过GetService方法调用同一个实例,可以理解为在局部实现了单例模式;

如果使用AddSingleton方法注册, 在整个应用程序生命周期内,IServiceProvider只会创建一个实例。

前面说到,接口我们是自动遍历响应的程序集进行注册的,注册接口的逻辑,我们可以统一抽取唯一个公用的函数处理,如下代码所示。

/// <summary>
        /// 配置依赖注入对象
        /// </summary>
        /// <param name="services"></param>
        public static void ConfigureRepository(IServiceCollection services)
        {
            #region 自动注入对应的服务接口
            var path = AppDomain.CurrentDomain.RelativeSearchPath ?? AppDomain.CurrentDomain.BaseDirectory;
            var getFiles = Directory.GetFiles(path, "*.dll").Where(Match);  //.Where(o=>o.Match())
            var referencedAssemblies = getFiles.Select(Assembly.LoadFrom).ToList();  //.Select(o=> Assembly.LoadFrom(o))       
            
            var baseType = typeof(IDependency);  
            var types = referencedAssemblies
                .SelectMany(a => a.DefinedTypes)
                .Select(type => type.AsType())
                .Where(x => x != baseType && baseType.IsAssignableFrom(x)).ToList();
            var implementTypes = types.Where(x => x.IsClass).ToList();
            var interfaceTypes = types.Where(x => x.IsInterface).ToList();
            RegisterService(services, implementTypes, interfaceTypes);
            #endregion
        }

如果我们这里增加一个对Web API的调用,那么在这里注册的时候,切换向Web API代理的注册接口就可以,如下图所示。

因此原来的Winform界面上的调用代码,不需要任何变化,只需要注入不同的接口实现,就能获得不同的方式:普通访问数据库方式,还是分布式获取服务WebAPI的处理方式。

通过切换开关变量的方式,客户可以非常方便的自由切换不同的数据访问方式。数据提供服务,可以是直接访问数据库的方式,也可以是远端的Web API服务方式,从而实现更加广泛的业务需求。

根据不同开关变量,处理不同的接口注册的代码如下所示。

/// <summary>
/// 根据配置文件,决定采用直连的DLL,还是代理API的DLL,构建接口进行注入
/// </summary>
/// <param name="services"></param>
public static void ConfigureRepositoryAuto(IServiceCollection services)
{
    var config = new AppConfig();
    string callerType = config.AppConfigGet("CallerType");
    if (!string.IsNullOrWhiteSpace(callerType) && callerType.Equals("api", StringComparison.OrdinalIgnoreCase))
    {
        //如果配置为API模式
        ConfigureRepositoryApi(services);
    }
    else
    {
        //如果配置为普通模式
        ConfigureRepository(services);
    }
}

API方式的注册,和普通的注册方式类似,就是定位具体的实现,获得接口和具体的实现对象,进行服务注册即可,在此不再赘述。

 

2、具体的Web API代理实现

在随笔《基于SqlSugar的开发框架循序渐进介绍(5)-- 在服务层使用接口注入方式实现IOC控制反转 》我们介绍过具体实现类的继承关系,一般都是构建相应的基类和接口,然后才是具体的业务实现和接口,这样处理可以重用基类的很多接口,提高代码的重用效率。

我们以其中简单的Customer业务表为例,它的服务类代码如下所示(主要关注服务类的定义即可)。

/// <summary>
    /// 客户信息应用层服务接口实现
    /// </summary>
    public class CustomerService : MyCrudService<CustomerInfo, string, CustomerPagedDto>, ICustomerService
    {
       ...............
    }

而对应Web API的代理调用类,那么为了极大的重用常规的接口处理,我们需要类似的继承关系。

具体的代码实现关系如下所示。

/// <summary>
/// 客户信息的Web API调用处理
/// </summary>
public class CustomerApiCaller : AsyncCrudApiCaller<CustomerInfo, string, CustomerPagedDto>, ICustomerService
{
}

我们可以利用代码生成工具生成主要的继承关系,然后实现具体的函数封装即可。我们独立一个项目用来承载API的代理类处理。

在AsyncCrudApiCaller 类中做了很多Web API的调用封装,对于接口的访问,是需要令牌的,因此在用户访问其他接口前,需要获取用户身份令牌信息,并缓存起来供后续使用。

/// <summary>
/// 对用户身份进行认证
/// </summary>
/// <param name="username">用户名</param>
/// <param name="password">用户密码</param>
/// <returns></returns>
public async virtual Task<AuthenticateResultDto> Authenticate(string username, string password)
{
    var url = string.Format("{0}/api/Login/Authenticate", ServerRootAddress);
    var input = new
    {
        UsernameOrEmailAddress = username,
        Password = password
    };
    var result = await apiClient.PostAsync<AuthenticateResultDto>(url, input);
    return result;
}

后续每次接口访问的时候,填入相应的令牌信息。

/// <summary>
/// 重新增加相应的请求头,如认证的信息
/// </summary>
protected virtual void AddRequestHeaders()
{
    //读取需要设置的请求头
    apiClient.RequestHeaders.Clear();
    foreach (var item in RequestHeaders)
    {
        apiClient.RequestHeaders.Add(item);
    }
    //从缓存里面读取令牌信息,并在请求的时候自动加入(如果没有加的话)
    var accessToken = Cache.Instance["AccessToken"] as string;
    if (!string.IsNullOrWhiteSpace(accessToken))
    {
        var bearer = new NameValue("Authorization", "Bearer " + accessToken);
        if (apiClient.RequestHeaders != null && !apiClient.RequestHeaders.Contains(bearer))
        {
            apiClient.RequestHeaders.Add(bearer);
        }
    }
}

而ApiCaller的实现类此对于具体的调用,由于封装了相应的处理类,因此操作代码是比较简单的。

/// <summary>
/// 获取所有对象列表
/// </summary>
/// <returns></returns>
public async virtual Task<ListResultDto<TEntity>> GetAllAsync()
{
    return await DoActionAsync<PagedResultDto<TEntity>>("all");
}
/// <summary>
/// 获取所有对象列表
/// </summary>
/// <param name="input">获取所有条件</param>
/// <returns></returns>
public async virtual Task<ListResultDto<TEntity>> GetAllByIdsAsync(IEnumerable<TPrimaryKey> input)
{
    return await DoActionAsync<PagedResultDto<TEntity>>("all-byids", input);
}

GET参数可以选用Dict方式传递,或者直接传入匿名类也可以,后台代码自动生成相关的URL参数传递的。

public async Task<bool> SetDeletedFlag(int id, bool deleted = true)
{
    var action = $"set-deleted";
    var input = new
    {
        id,
        deleted
    };
    return await DoActionAsync<bool>(action, input, HttpVerb.Post);
}
public async Task<OuInfo> FindByName(string name)
{
    var action = $"byname/{name}";
    var dict = new Dictionary<string, string> { { "name", name } };
    return await DoActionAsync<OuInfo>(action, dict, HttpVerb.Get);
}

剩下的任务就是完善ApiCaller项目的类,与Web API控制器提供的接口的对应关系了,处理完成后,就可以进行测试了。

只要做好模块接口的对接关系,界面的处理代码不用变化就可以切换到其他方式上去了(如Web API的数据提供方式)。

 

系列文章:

基于SqlSugar的开发框架的循序渐进介绍(1)--框架基础类的设计和使用

基于SqlSugar的开发框架循序渐进介绍(2)-- 基于中间表的查询处理

基于SqlSugar的开发框架循序渐进介绍(3)-- 实现代码生成工具Database2Sharp的整合开发

基于SqlSugar的开发框架循序渐进介绍(4)-- 在数据访问基类中对GUID主键进行自动赋值处理

基于SqlSugar的开发框架循序渐进介绍(5)-- 在服务层使用接口注入方式实现IOC控制反转

基于SqlSugar的开发框架循序渐进介绍(6)-- 在基类接口中注入用户身份信息接口

基于SqlSugar的开发框架循序渐进介绍(7)-- 在文件上传模块中采用选项模式【Options】处理常规上传和FTP文件上传

基于SqlSugar的开发框架循序渐进介绍(8)-- 在基类函数封装实现用户操作日志记录

基于SqlSugar的开发框架循序渐进介绍(9)-- 结合Winform控件实现字段的权限控制

基于SqlSugar的开发框架循序渐进介绍(10)-- 利用axios组件的封装,实现对后端API数据的访问和基类的统一封装处理

基于SqlSugar的开发框架循序渐进介绍(11)-- 使用TypeScript和Vue3的Setup语法糖编写页面和组件的总结

基于SqlSugar的开发框架循序渐进介绍(12)-- 拆分页面模块内容为组件,实现分而治之的处理

基于SqlSugar的开发框架循序渐进介绍(13)-- 基于ElementPlus的上传组件进行封装,便于项目使用

基于SqlSugar的开发框架循序渐进介绍(14)-- 基于Vue3+TypeScript的全局对象的注入和使用

基于SqlSugar的开发框架循序渐进介绍(15)-- 整合代码生成工具进行前端界面的生成

基于SqlSugar的开发框架循序渐进介绍(16)-- 工作流模块的功能介绍

基于SqlSugar的开发框架循序渐进介绍(17)-- 基于CSRedis实现缓存的处理

基于SqlSugar的开发框架循序渐进介绍(18)-- 基于代码生成工具Database2Sharp,快速生成Vue3+TypeScript的前端界面和Winform端界面

基于SqlSugar的开发框架循序渐进介绍(19)-- 基于UniApp+Vue的移动前端的功能介绍

基于SqlSugar的开发框架循序渐进介绍(20)-- 在基于UniApp+Vue的移动端实现多条件查询的处理

基于SqlSugar的开发框架循序渐进介绍(21)-- 在工作流列表页面中增加一些转义信息的输出,在后端进行内容转换

基于SqlSugar的开发框架循序渐进介绍(22)-- Vue3+TypeScript的前端工作流模块中实现统一的表单编辑和表单详情查看处理

基于SqlSugar的开发框架循序渐进介绍(23)-- Winform端管理系统中平滑增加对Web API对接的需求

基于SqlSugar的开发框架循序渐进介绍(24)-- 使用Serialize.Linq对Lambda表达式进行序列化和反序列化

 

专注于代码生成工具、.Net/.NetCore 框架架构及软件开发,以及各种Vue.js的前端技术应用。著有Winform开发框架/混合式开发框架、微信开发框架、Bootstrap开发框架、ABP开发框架、SqlSugar开发框架等框架产品。
 转载请注明出处:撰写人:伍华聪  http://www.iqidi.com

相关文章
|
1月前
|
监控 算法 API
电商API接口对接实录:淘宝优惠券接口对接处理促销监控系统
在电商开发中,淘宝详情页的“券后价计算”是极易出错的环节。本文作者结合实战经验,分享了因忽略满减券门槛、有效期、适用范围等导致的踩坑经历,并提供了完整的解决方案,包括淘宝API签名生成、券后价计算逻辑、常见坑点及优化建议,助力开发者精准实现券后价功能,避免业务损失。
|
1月前
|
监控 算法 API
电商API接口实录对接:1688混批价格函数处理
本文分享了作者近十年电商开发中对接1688商品详情API的实战经验,涵盖权限申请、签名验证、阶梯价格、库存解析及限流控制等关键问题,并提供Python代码示例,助力开发者高效应对1688开发中的挑战。
|
2月前
|
JSON 监控 网络协议
干货分享“对接的 API 总是不稳定,网络分层模型” 看电商 API 故障的本质
本文从 OSI 七层网络模型出发,深入剖析电商 API 不稳定的根本原因,涵盖物理层到应用层的典型故障与解决方案,结合阿里、京东等大厂架构,详解如何构建高稳定性的电商 API 通信体系。
|
2月前
|
边缘计算 监控 Java
跨境电商 API 对接避坑指南:亚马逊 SP-API 超时问题的 5 种解决方案(附重试代码模板)
在对接亚马逊 SP-API 时,超时问题常导致订单延迟、库存失败,影响运营。本文总结某 3C 品牌实战经验,详解超时的 3 大根源与 5 大解决方案,涵盖动态超时、重试机制、请求拆分、并发控制与边缘加速,并附可复用 Python 代码,助你将超时率从 20% 降至 1% 以下。
|
3月前
|
数据采集 机器学习/深度学习 搜索推荐
利用通义大模型构建个性化推荐系统——从数据预处理到实时API部署
本文详细介绍了基于通义大模型构建个性化推荐系统的全流程,涵盖数据预处理、模型微调、实时部署及效果优化。通过采用Qwen-72B结合LoRA技术,实现电商场景下CTR提升58%,GMV增长12.7%。文章分析了特征工程、多任务学习和性能调优的关键步骤,并探讨内存优化与蒸馏实践。最后总结了大模型在推荐系统中的适用场景与局限性,提出未来向MoE架构和因果推断方向演进的建议。
519 10
|
2月前
|
JSON 搜索推荐 算法
利用API提升电商用户体验:个性化推荐系统
在电商竞争激烈的当下,个性化推荐系统成为提升用户粘性与转化率的关键。本文详解如何通过API集成高效接入先进推荐算法,实现实时精准推荐,优化用户体验,提升业务增长。
141 0
|
30天前
|
人工智能 JSON 算法
抖音电商 API 赋能,抖音平台达人合作数据精准对接
抖音电商API为品牌与达人合作提供精准数据对接,提升匹配效率与营销精准度,助力电商生态智能化升级。
125 1
|
1月前
|
监控 安全 BI
电商 API 助力,多平台物流信息无缝对接
在电商多平台运营中,物流信息割裂导致效率低下、客服压力大。通过API技术,可实现订单抓取、状态同步与数据聚合,打通电商平台、快递系统与商家ERP,提升运营效率与用户体验。
107 0
|
3月前
|
缓存 自然语言处理 监控
基于通义大模型的智能客服系统构建实战:从模型微调到API部署
本文详细解析了基于通义大模型的智能客服系统构建全流程,涵盖数据准备、模型微调、性能优化及API部署等关键环节。通过实战案例与代码演示,展示了如何针对客服场景优化训练数据、高效微调大模型、解决部署中的延迟与并发问题,以及构建完整的API服务与监控体系。文章还探讨了性能优化进阶技术,如模型量化压缩和缓存策略,并提供了安全与合规实践建议。最终总结显示,微调后模型意图识别准确率提升14.3%,QPS从12.3提升至86.7,延迟降低74%。
1014 14
|
2月前
|
监控 数据可视化 API
低代码平台对接API:无需编程快速搭建电商数据中台
低代码平台助力电商企业快速搭建数据中台,通过可视化操作整合京东、淘宝等多平台API,实现库存监控、价格对比、订单分析等功能,降低技术门槛,提升运营效率。