Team.Feeder.Core

Team.Feeder.Core 提供设备实现层复用的基础设施。它不负责具体协议，但负责把“一个设备实现应该怎样维护状态、怎样限制生命周期流转、怎样输出稳定错误”这类共性逻辑收敛起来。

适用场景

• 你正在实现一个新的 IFeeder，不想从零写状态管理和事件转发。
• 你希望设备实现遵守统一的生命周期状态机。
• 你需要把底层异常映射为稳定、可展示的公共错误模型。

包内提供的核心能力

安装

dotnet add package Team.Feeder.Core

安装本包时会自动拉取 Team.Feeder.Abstractions。

最常见的使用方式：继承 FeederBase

using Team.Feeder.Abstractions.Enums;
using Team.Feeder.Abstractions.Models;
using Team.Feeder.Core.Base;

public sealed class DemoFeeder : FeederBase
{
	public DemoFeeder(Guid id, string name)
		: base(id, name, new FeederDescriptor
		{
			DeviceType = "DemoFeeder",
			DisplayName = name,
			CapabilityTags = new[] { "demo" },
		})
	{
	}

	public override async Task ConnectAsync(CancellationToken cancellationToken = default)
	{
		cancellationToken.ThrowIfCancellationRequested();

		try
		{
			await Task.Delay(50, cancellationToken);
			await base.ConnectAsync(cancellationToken);
		}
		catch (Exception ex)
		{
			SetFaulted(ex, "Connect", "demo");
			throw;
		}
	}
}

这个模式的好处是：

• Id、Name、Descriptor、Status 和 StatusChanged 都由基类统一维护。
• 每次状态切换都会经过 FeederStateMachine 校验。
• 你只需要把设备专属的通信逻辑填进去。

什么时候直接使用 FeederStateMachine

如果你没有继承 FeederBase，但仍想沿用 Team.Feeder 的状态机规则，可以在自己的实现中显式调用：

if (!FeederStateMachine.CanTransition(currentState, nextState))
{
	throw new InvalidOperationException("Illegal feeder state transition.");
}

什么时候使用 FeederExceptionFactory

当你的底层协议层可能抛出 SocketException、IOException、TimeoutException 等异常时，可以在边界层把它们转成可展示的公共错误：

try
{
	await transport.SendAsync(payload, cancellationToken);
}
catch (Exception ex)
{
	var error = FeederExceptionFactory.CreateError(ex, operation: "Send", source: "transport");
	Console.WriteLine($"{error.Code}: {error.Message}");
}

与其他包的关系

• 如果你只是使用现成的 FFFeeder 设备实现，通常直接引用 Team.Feeder.FFFeeder 即可，不需要单独依赖本包。
• 如果你在做新的设备驱动包，本包通常应该和 Team.Feeder.Abstractions 一起使用。
• Team.Feeder.Service 可以复用这里的稳定错误收敛方式，但不应该把设备专属协议逻辑塞进来。

边界说明

• 这里不放设备私有寄存器、协议命令、地址表。
• 这里不放多设备注册表和宿主持久化逻辑。
• 这里不放 UI 控件和本地化资源。

如果某段逻辑只能服务于一个具体设备，那它通常不应该进入 Team.Feeder.Core。