多场景抢红包业务引发.NETCore下使用适配器模式实现业务接口分离
事情的起因
我们公司现有一块业务叫做抢红包,最初的想法只是实现了一个初代版本,就是给指定的好友单发红包,随着业务的发展,发红包和抢红包的场景也越来越多,目前主要应用的场景有:单聊发红包、群聊发红包、名片发红包、直播场景中的主播发红包/观众给主播发红包/定时抢红包,接下来,如果出现其它产品的业务,也将大概率的出现抢红包的需求。
大同小异的抢红包业务
红包的场景无论怎么变化,其核心算法不变,这部分是可以抽象的内容,随着迭代发展,我们之前通常都是通过增加红包的类型(业务)来扩展,但是随着肉眼可见的发展,部分业务的改动如果需要对红包业务进行调整和优化对话,将有可能产生牵一发而动全身的debuff效果。
新的改变
其实这些业务代码早该优化一下,我就是懒+忙(借口),正好有位新同事入职,这块的优化任务就交给他来做了,从头到尾我都没有参与(不知道有没有吐槽我的代码,捂脸~),我初步看了一下,代码的实现质量还是挺高的,正好也是一个比较好的应用场景,我就简单实现一下他做的适配器模式,彻底的将各个红包业务类型分离,很好的实现了设计模式的开闭原则,加入某天某个场景的抢红包业务下线了,这种做法是非常有利于业务的扩展和维护。
定义抢红包接口
public interface IRedPacket
{
string Name { get; }
string Put(int org_id, int money, int count, string reason);
string Get(int id);
}
以上接口包含一个属性和2个方法,用于设置业务名称和收发红包。初次之外,我们还需要定义一个实现业务的基类,用于处理公共业务。
红包基类业务实现
public abstract class RedPacket : IRedPacket
{
public abstract string Name { get; }
public abstract string Put(int org_id, int money, int count, string reason);
public abstract string Get(int id);
protected string Create(string reason, int money, int count)
{
Console.WriteLine("创建了红包:{0},金额:Money:{1},数量:{2}", reason, money, count);
return "成功";
}
protected string Fighting()
{
Console.WriteLine("调用了抢红包方法:{0}", nameof(Fighting));
return "成功";
}
}
在基类中,我们选择不实现接口,将接口方法定义为抽象类型。同时,定义并实现两个受保护的方法 Create(创建红包)/Fighting(抢红包),接口方法由子类实现具体的业务细节,当子类针对具体的业务细节实现完成后,他们应该会调用Create(创建红包)/Fighting(抢红包)的方法,直至最终完成整个红包的流程。
实现单聊红包
public class ChatOneRedPacket : RedPacket
{
public override string Name { get; } = "ChatOne";
public override string Put(int org_id, int money, int count, string reason)
{
Console.WriteLine("检查接收人ID:{0}是否存在", org_id);
return base.Create(reason, money, count);
}
public override string Get(int id)
{
Console.WriteLine("检查红包ID:{0},是否具有领取资格", id);
return base.Fighting();
}
}
群聊红包
public class ChatGroupRedPacket : RedPacket
{
public override string Name { get; } = "ChatGroup";
public override string Put(int org_id, int money, int count, string reason)
{
Console.WriteLine("检查群ID:{0},是否存在", org_id);
return base.Create(reason, money, count);
}
public override string Get(int id)
{
Console.WriteLine("检查是否群ID:{0},当前用户是否群成员", id);
return base.Fighting();
}
}
直播红包
public class LiveRedPacket : RedPacket
{
public override string Name { get; } = "Live";
public override string Put(int org_id, int money, int count, string reason)
{
Console.WriteLine("检查直播ID:{0}是否存在", org_id);
return base.Create(reason, money, count);
}
public override string Get(int id)
{
Console.WriteLine("检查红包ID:{0} 是否当前主播红包", id);
return base.Fighting();
}
}
为了方便演示,上面的三种红包子类仅简单的实现类属性 Name="ChatOne",除此之外,还实现类接口的收发红包接口,子类实现 Name 属性主要是便于我们在DI中去灵活的区分调用的主体,实现业务的分离。除了单聊红包外,我们还有群聊和直播红包,都采用上面的处理方式,只是各自实现的 Name 属性时,指定不同的名字即可。在接口实现的方法中,各自的业务还需要执行不同的业务检查,比如单聊红包就需要检查接收人是否存在,群聊红包还需要检查群是否存在,该群是否被冻结等等,直播红包需要检查主播是否在直播中,观众是否在直播房间内,这些都是不同业务场景产生的特殊的业务处理需求。
创建容器实例
public void ConfigureServices(IServiceCollection services)
{
services.AddScoped(typeof(IRedPacket), typeof(ChatOneRedPacket))
.AddScoped(typeof(IRedPacket), typeof(ChatGroupRedPacket))
.AddScoped(typeof(IRedPacket), typeof(LiveRedPacket));
...
}
容器实例的创建非常简单,只需要将已实现 IRedPacket 接口的子类注册到服务管道即可。
依赖注入,以实例集的方式
[Route("api/[controller]")]
[ApiController]
public class HomeController : ControllerBase
{
private readonly IEnumerable<IRedPacket> redpackets;
public HomeController(IEnumerable<IRedPacket> redpackets)
{
this.redpackets = redpackets;
}
}
通过建立一个控制台 HomeController 用于演示,在 HomeController 的构造方法中,使用 IEnumerable 获得在服务中创建的所有实现接口 IRedPacket 的实例。下面将在 HomeController 中 创建两个接口进行演示发红包/抢红包。
发红包
[HttpPost]
public ActionResult<string> Post([FromBody] RedPacketViewModel model)
{
var rp = this.redpackets.Where(f => f.Name == model.Type).FirstOrDefault();
if (rp == null)
{
var msg = $"红包业务类型:{model.Type}不存在";
Console.WriteLine(msg);
return msg;
}
var result = rp.Put(model.Org_Id, model.Money, model.Count, model.Reason);
return result;
}
为了演示方便,我们构造4中不同的业务实体去调用发红包的接口,分别将结果输出到客户端
// 单聊红包
{
"type":"ChatOne",
"org_id":1,
"money":8,
"count":1,
"reason":"恭喜发财,大吉大利!"
}
// 群聊红包
{
"type":"ChatGroup",
"org_id":2,
"money":9,
"count":3,
"reason":"恭喜发财,大吉大利!"
}
// 直播红包
{
"type":"Live",
"org_id":3,
"money":8,
"count":1,
"reason":"恭喜发财,大吉大利!"
}
//圈子红包
{
"type":"Quanzi",
"org_id":4,
"money":8,
"count":1,
"reason":"恭喜发财,大吉大利!"
}
输出结果为:
// 单聊红包
检查接收人ID:1是否存在
红包类型:ChatOne,创建了红包:恭喜发财,大吉大利!,金额:Money:8,数量:1
// 群聊红包
检查群ID:2,是否存在
红包类型:ChatGroup,创建了红包:恭喜发财,大吉大利!,金额:Money:9,数量:3
// 直播红包
检查直播ID:3是否存在
红包类型:Live,创建了红包:恭喜发财,大吉大利!,金额:Money:8,数量:1
//圈子红包
红包业务类型:Quanzi不存在
抢红包
[HttpGet("{id}")]
public ActionResult<string> Get(int id)
{
// 生产环境下,该红包消息应该是从数据库中读取
var model = GetRedPacket(id);
var rp = this.redpackets.Where(f => f.Name == model.Type).FirstOrDefault();
var result = rp.Get(id);
return result;
}
private RedPacketViewModel GetRedPacket(int id)
{
int type = --id;
string[] redPackets = { "ChatOne", "ChatGroup", "Live" };
var model = new RedPacketViewModel
{
Count = 3,
Money = 8,
Org_Id = 115,
Reason = "恭喜发财,大吉大利!",
Type = redPackets[type]
};
return model;
}
抢红包的过程,传入一个红包ID,然后跟进该ID到数据库进行查找,得到红包后,根据红包类型找出 IRedPacket 的实现类,并进行调用,完成抢红包的操作。可能有的同学会觉得比较奇怪,为什么不直接拆红包呢?这是因为我们要根据红包设计的初衷,不同的红包,其所执行的业务规范性检查是不同的,不能直接进行暴力拆包。
结束语
上面我们创建了3个IRedPacket的实现类,并将他们注册到服务管道中,然后在HomeController中获得服务依赖注入的实例对象,通过在不同的参数传入,实现了不同的红包业务场景的拆分,很好的实现了设计模式中所说的开闭原则。
演示代码下载
https://github.com/lianggx/Examples/tree/master/Ron.RedPacketTest
多场景抢红包业务引发.NETCore下使用适配器模式实现业务接口分离的更多相关文章
- .NetCore 下开发独立的(RPL)含有界面的组件包 (六)实现业务功能
.NetCore 下开发独立的(RPL)含有界面的组件包 (一)准备工作 .NetCore 下开发独立的(RPL)含有界面的组件包 (二)扩展中间件及服 务 .NetCore 下开发独立的(RPL)含 ...
- .NetCore 下开发独立的(RPL)含有界面的组件包 (五)授权过滤参数处理
.NetCore 下开发独立的(RPL)含有界面的组件包 (一)准备工作 .NetCore 下开发独立的(RPL)含有界面的组件包 (二)扩展中间件及服 务 .NetCore 下开发独立的(RPL)含 ...
- .NetCore 下开发独立的(RPL)含有界面的组件包 (四)授权过滤
.NetCore 下开发独立的(RPL)含有界面的组件包 (一)准备工作 .NetCore 下开发独立的(RPL)含有界面的组件包 (二)扩展中间件及服 务 .NetCore 下开发独立的(RPL)含 ...
- .NetCore 下开发独立的(RPL)含有界面的组件包 (三)构建界面
.NetCore 下开发独立的(RPL)含有界面的组件包 (一)准备工作 .NetCore 下开发独立的(RPL)含有界面的组件包 (二)扩展中间件及服 务 .NetCore 下开发独立的(RPL)含 ...
- .NetCore 下开发独立的(RPL)含有界面的组件包 (二)扩展中间件及服务
.NetCore 下开发独立的(RPL)含有界面的组件包 (一)准备工作 .NetCore 下开发独立的(RPL)含有界面的组件包 (二)扩展中间件及服 务 .NetCore 下开发独立的(RPL)含 ...
- .NetCore 下开发独立的(RPL)含有界面的组件包 (一)准备工作
.NetCore 下开发独立的(RPL)含有界面的组件包 (一)准备工作 .NetCore 下开发独立的(RPL)含有界面的组件包 (二)扩展中间件及服 务 .NetCore 下开发独立的(RPL)含 ...
- .netcore下的微服务、容器、运维、自动化发布
原文:.netcore下的微服务.容器.运维.自动化发布 微服务 1.1 基本概念 1.1.1 什么是微服务? 微服务架构是SOA思想某一种具体实现.是一种将单应用程序作为一套小型 ...
- 我们NetCore下日志存储设计
日志的分类 首先往大的来说,日志分2种 ①业务日志: 即业务系统需要查看的日志, 常见的比如谁什么时候修改了什么. ②参数日志: 一般是开发人员遇到问题的时候定位用的, 一般不需要再业务系统里展示. ...
- NetCore下模拟和使用Modbus工业通信协议
Tips: 1.目前NetCore下与Modbus通信的框架主要选择了 Modbus.Net https://github.com/parallelbgls/Modbus.Net 2.modbus是 ...
随机推荐
- Vue 路由模块化配置
博客地址:https://ainyi.com/77 企业运营后台页面很多,路由如若不区分模块化配置,所有路由挤在同一个文件将不好维护,所以路由的配置也要模块化 分享两个解决方案 -- Vue 路由配置 ...
- tracert和traceroute介绍
一.tracert和traceroute简介 相同点:都是用来跟踪路由,帮助排查问题,关注的是过程,而ping关注的是结果 不同点:tracert请求是icmp echo报文 traceroute请求 ...
- python模块之junos-eznc
一.简介 本文将使用python模块中的junos-eznc来控制juniper的 Junos OS系统,此模块可以在windows平台和UNIX平台上使用 二.实验环境 1.操作系统:win10 2 ...
- jmeter+Fiddler:通过Fiddler抓包生成jmeter脚本
Fiddler是目前最常用的抓包工具之一,它作为客户端和服务器端之间的代理,记录客户端和服务器之间的所有请求(http/https),可以针对特定的请求过滤,分析请求和响应的数据.设置断点.调试.修改 ...
- 谈谈JVM垃圾回收
概述 Java运行时区域中,程序计数器,虚拟机栈,本地方法栈三个区域随着线程的而生,随线程而死,这几个区域的内存分配和回收都具备确定性,不需要过多考虑回收问题.而Java堆和方法区则不一样,一个接口的 ...
- JavaScript中一个方法同时发送两个ajax请求问题
今天在做项目中遇到一个问题,大概是在一个jsp页面同时有一个select下拉搜索条件框和一个Bootstrap表格展示列表.这两个都要通过ajax向后台拿数据,而且要在页面加载时完成.当时的做法是: ...
- 高并发下,调整IIS相关的设置,以提高服务器并发量
1.修改 IIS 队列长度 参考资料:https://docs.microsoft.com/zh-cn/previous-versions/office/communications-server/d ...
- GPU服务器安装NVIDIA驱动以及CUDA
1.安装系统 系统版本: ubuntu16.04.05 LTS 分区要求: /boot 1024M swap 64G / 剩余空间
- Docker学习总结(三)--常用命令
镜像相关命令 查看镜像 docker images 返回列表字段含义如下: 字段名称 字段含义 REPOSITORY 镜像名称 TAG 镜像标签 IMAGE ID 镜像 ID CREATED 镜像创建 ...
- (一)配置linux环境实现持续集成
目录 1.Centos7操作系统 2.Gnome 可视化桌面 3.远程shell工具 4.远程桌面工具 5.Jdk 6..Net Core 7.Git 8.Docker 容器 9.Kubernetes ...