多场景抢红包业务引发.NETCore下使用适配器模式实现业务接口分离
<h2 id="事故的因由">事故的因由</h2><p>我们公司现有一块业务叫做抢红包，最初的想法只是实现了一个初代版本，就是给指定的好友单发红包，随着业务的发展，发红包和抢红包的场景也越来越多，目前主要应用的场景有：单聊发红包、群聊发红包、名片发红包、直播场景中的主播发红包/观众给主播发红包/定时抢红包，接下来，如果出现其它产品的业务，也将大概率的出现抢红包的需求。</p>
<h2 id="大同小异的抢红包业务">大同小异的抢红包业务</h2>
<p>红包的场景无论怎么厘革，其核默算法稳定，这部分是可以抽象的内容，随着迭代发展，我们之前通常都是通过增长红包的类型（业务）来扩展，但是随着肉眼可见的发展，部分业务的改动如果需要对红包业务进行调解和优化对话，将有可能产生牵一发而动满身的debuff效果。</p>
<h2 id="新的改变">新的改变</h2>
<p>其实这些业务代码早该优化一下，我就是懒+忙（借口），恰好有位新同事入职，这块的优化任务就交给他来做了，从头至尾我都没有到场（不知道有没有吐槽我的代码，捂脸～），我开端看了一下，代码的实现质量还是挺高的，恰好也是一个比力好的应用场景，我就简朴实现一下他做的适配器模式，彻底的将各个红包业务类型分离，很好的实现了计划模式的开闭原则，加入某天某个场景的抢红包业务下线了，这种做法是非常有利于业务的扩展和维护。</p>
<h2 id="界说抢红包接口">界说抢红包接口</h2>
<code>public interface IRedPacket
{
string Name { get; }
string Put(int org_id, int money, int count, string reason);
string Get(int id);
}</code>
<p>以上接口包含一个属性和2个方法，用于设置业务名称和收发红包。初次之外，我们还需要界说一个实现业务的基类，用于处理惩罚公共业务。</p>
<h2 id="红包基类业务实现">红包基类业务实现</h2>
<code>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 "乐成";
}
}</code>
<p>在基类中，我们选择不实现接口，将接口方法界说为抽象类型。同时，界说并实现两个受保护的方法 Create（创建红包）/Fighting（抢红包），接口方法由子类实现具体的业务细节，当子类针对具体的业务细节实现完成后，他们应该会调用Create（创建红包）/Fighting（抢红包）的方法，直至最终完成整个红包的流程。</p>
<h2 id="实现单聊红包">实现单聊红包</h2>
<code> 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();
}
}</code>
<h2 id="群聊红包">群聊红包</h2>
<code>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();
}
}</code>
<h2 id="直播红包">直播红包</h2>
<code>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();
}
}</code>
<p>为了方便演示，上面的三种红包子类仅简朴的实现类属性 Name="ChatOne"，除此之外，还实现类接口的收发红包接口，子类实现 Name 属性主要是便于我们在DI中去机动的区分调用的主体，实现业务的分离。除了单聊红包外，我们另有群聊和直播红包，都接纳上面的处理惩罚方式，只是各自实现的 Name 属性时，指定差异的名字即可。在接口实现的方法中，各自的业务还需要执行差异的业务检查，好比单聊红包就需要检查接收人是否存在，群聊红包还需要检查群是否存在，该群是否被冻结等等，直播红包需要检查主播是否在直播中，观众是否在直播房间内，这些都是差异业务场景产生的特殊的业务处理惩罚需求。</p>
<h2 id="创建容器实例">创建容器实例</h2>
<code>public void ConfigureServices(IServiceCollection services)
{
services.AddScoped(typeof(IRedPacket), typeof(ChatOneRedPacket))
.AddScoped(typeof(IRedPacket), typeof(ChatGroupRedPacket))
.AddScoped(typeof(IRedPacket), typeof(LiveRedPacket));
...
}</code>
<p>容器实例的创建非常简朴，只需要将已实现 IRedPacket 接口的子类注册到服务管道即可。</p>
<h2 id="依赖注入以实例集的方式">依赖注入，以实例集的方式</h2>
<code>")]
public class HomeController : ControllerBase
{
private readonly IEnumerable<IRedPacket> redpackets;
public HomeController(IEnumerable<IRedPacket> redpackets)
{
this.redpackets = redpackets;
}
}</code>
<p>通过创建一个控制台 HomeController 用于演示，在 HomeController 的构造方法中，使用 IEnumerable<IRedPacket> 得到在服务中创建的全部实现接口 IRedPacket 的实例。下面将在 HomeController 中 创建两个接口进行演示发红包/抢红包。</p>
<h2 id="发红包">发红包</h2>
<code>
public ActionResult<string> Post( 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;
}</code>
<p>为了演示方便，我们构造4中差异的业务实体去调用发红包的接口，分别将效果输出到客户端</p>
<code>// 单聊红包
{
"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":"恭喜发财，大吉大利！"
}</code>
<p>输出效果为：</p>
<code>// 单聊红包
检查接收人ID:1是否存在
红包类型：ChatOne，创建了红包:恭喜发财，大吉大利！,金额：Money:8,数量:1
// 群聊红包
检查群ID：2,是否存在
红包类型：ChatGroup，创建了红包:恭喜发财，大吉大利！,金额：Money:9,数量:3
// 直播红包
检查直播ID:3是否存在
红包类型：Live，创建了红包:恭喜发财，大吉大利！,金额：Money:8,数量:1
//圈子红包</code>
<p>红包业务类型：Quanzi不存在</p>
<h2 id="抢红包">抢红包</h2>
<code>
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
};
return model;
}</code>
<p>抢红包的过程，传入一个红包ID,然后跟进该ID到数据库进行查找，得到红包后，根据红包类型找出 IRedPacket 的实现类，并进行调用，完成抢红包的操作。可能有的同砚会以为比力奇怪，为什么不直接拆红包呢？这是由于我们要根据红包计划的初志，差异的红包，其所执行的业务规范性检查是差异的，不能直接进行暴力拆包。</p>
<h2 id="竣事语">竣事语</h2>
<p>上面我们创建了3个IRedPacket的实现类，并将他们注册到服务管道中，然后在HomeController中得到服务依赖注入的实例对象，通过在差异的参数传入，实现了差异的红包业务场景的拆分，很好的实现了计划模式中所说的开闭原则。</p>
<h2 id="演示代码下载">演示代码下载</h2>
<p>https://github.com/lianggx/Examples/tree/master/Ron.RedPacketTest</p><br><br/><br/><br/><br/><br/>来源：<a href="https://www.cnblogs.com/viter/p/11532822.html" target="_blank">https://www.cnblogs.com/viter/p/11532822.html</a>
页:
[1]