下述Topshelf创建Windows服务的代码是否使用Options模式？其直观写法是什么

是否采用Options模式？ #

这段代码没有使用.NET标准定义的Options模式。

• .NET的Options模式核心是强类型配置对象与配置源绑定、通过IOptions<TOptions>接口注入获取配置值的整套实现，一般和配置文件、环境变量等配置源搭配使用。
• 这段Topshelf库的代码用的是生成器（Builder）模式的Fluent API写法：通过传入Action委托，在委托内部调用宿主配置对象的方法完成服务参数设置，和Options模式的实现逻辑完全无关。

改写为更直观的形式 #

原代码用了匿名Lambda的简写形式，隐去了配置对象的类型信息，对不熟悉Fluent API的开发者不够友好。把简写的Lambda拆为显式的配置方法、补充必要注释后，逻辑会清晰很多，代码和原逻辑完全等价：

static void Main(string[] args)
{
    // 显式定义宿主配置逻辑
    void SetupTopshelfHost(HostConfigurator configurator)
    {
        // 指定服务的核心实现类
        configurator.Service<LoggingService>();

        // 开启服务故障恢复策略：服务异常退出后10秒自动重启
        configurator.EnableServiceRecovery(recoveryOption =>
        {
            recoveryOption.RestartService(TimeSpan.FromSeconds(10));
        });

        // 设置Windows服务在系统中的服务名
        configurator.SetServiceName("TestService");

        // 设置服务启动方式为开机自动启动
        configurator.StartAutomatically();
    }

    // 传入配置规则，启动Topshelf服务宿主
    HostFactory.Run(SetupTopshelfHost);
}

如果要进一步降低理解门槛，还可以把嵌套的恢复规则配置也单独拆分出来，清晰展示每一层配置对应的对象类型：

static void Main(string[] args)
{
    // 单独定义故障恢复规则
    void SetupServiceRecovery(ServiceRecoveryConfigurator recoveryConfig)
    {
        recoveryConfig.RestartService(TimeSpan.FromSeconds(10));
    }

    // 单独定义宿主整体配置
    void SetupTopshelfHost(HostConfigurator configurator)
    {
        configurator.Service<LoggingService>();
        configurator.EnableServiceRecovery(SetupServiceRecovery);
        configurator.SetServiceName("TestService");
        configurator.StartAutomatically();
    }

    HostFactory.Run(SetupTopshelfHost);
}

注：原匿名Lambda的写法是C#生态中配置类API的常见简写形式，生产环境直接使用没有问题，拆分写法仅用于降低理解门槛。

内容的提问来源于stack exchange，提问作者Rod