C# 多服务实现同一接口时如何支持不同参数与返回值

可以实现，优先使用泛型接口方案，完全匹配你给出的示例效果，支持编译期类型检查。
注意：不要使用方法级泛型定义（将泛型参数声明在方法而非接口上），这种写法要求实现类必须兼容任意类型的入参、返回值，无法实现每个服务方法固定参数、返回类型的效果。

直接为统一接口定义对应每个方法的参数、响应泛型参数，实现服务时明确指定自身使用的具体类型即可，和你写的示例代码结构完全一致。

接口定义 #

// 为接口的每个方法分别定义参数、返回值的泛型占位符
public interface IService<TGetParams, TGetResponse, TMethod2Params, TMethod2Response>
{
    TGetResponse Get(TGetParams @params);
    TMethod2Response Method2(TMethod2Params @params);
}

ServiceA实现 #

public class ZParams{}
public class ZResponse{}

public class YParams{}
public class YResponse{}

public class ServiceA : IService<ZParams, ZResponse, YParams, YResponse>
{    
    public ZResponse Get(ZParams @params)
    {
        // 业务逻辑
        return default;
    }

    public YResponse Method2(YParams @params)
    {
        // 业务逻辑
        return default;
    }
}

ServiceB实现 #

public class FParams{}
public class FResponse{}

public class GParams{}
public class GResponse{}

public class ServiceB : IService<FParams, FResponse, GParams, GResponse>
{
    public FResponse Get(FParams @params)
    {
        // 业务逻辑
        return default;
    }

    public GResponse Method2(GParams @params)
    {
        // 业务逻辑
        return default;
    }
}

方案说明 #

• 优势：编译期即可完成类型校验，无运行时类型转换开销，代码结构和你预期的写法完全一致。
• 局限：如果接口后续新增方法，需要同步增加对应的泛型参数，方法数量较多时泛型列表会变长。

如果需要做通用的服务调度、动态代理，不要求编译期强类型校验，可以让所有参数、响应类型继承统一的标记接口，实现类内部做类型校验。

接口与基类定义 #

// 统一标记接口
public interface IServiceParams{}
public interface IServiceResponse{}

public interface IService
{
    IServiceResponse Get(IServiceParams @params);
    IServiceResponse Method2(IServiceParams @params);
}

服务实现示例 #

public class FParams : IServiceParams{}
public class FResponse : IServiceResponse{}

public class GParams : IServiceParams{}
public class GResponse : IServiceResponse{}

public class ServiceB : IService
{
    public IServiceResponse Get(IServiceParams @params)
    {
        if (@params is not FParams fParams)
            throw new ArgumentException($"参数类型不匹配，预期类型为{nameof(FParams)}");
        // 业务逻辑处理fParams
        return new FResponse();
    }

    public IServiceResponse Method2(IServiceParams @params)
    {
        if (@params is not GParams gParams)
            throw new ArgumentException($"参数类型不匹配，预期类型为{nameof(GParams)}");
        // 业务逻辑处理gParams
        return new GResponse();
    }
}

方案说明 #

• 优势：接口定义固定，后续新增方法不需要调整泛型参数，适合做通用网关、服务总线这类需要动态处理不同类型请求的场景。
• 局限：没有编译期类型检查，参数类型错误只能在运行时抛出异常，存在额外的类型转换开销。

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