我们使用aspnet-api-version来控制我们的应用程序接口的版本,而这个库允许在一个控制器上使用interleaving multiple version implementation。
[ApiVersion( "2.0" )]
[ApiVersion( "3.0" )]
[RoutePrefix( "api/helloworld" )]
public class HelloWorld2Controller : ApiController
{
[Route]
public string Get() => "Hello world v2.0!";
[Route, MapToApiVersion( "3.0" )]
public string GetV3() => "Hello world v3.0!";
}我们希望保持特定于版本的控制器独立。
我看到的版本特定的控制器和使用这个库的问题是,我们必须重新实现所有的API方法,而不管它们是否已经改变。考虑这个例子
[RoutePrefix("api/v{version:apiVersion}/values")]
[ApiVersion( "1.0" )]
public class ValuesController : ApiController
{
// GET api/values
[Route]
public IEnumerable<string> Get()
{
return new string[] { "value1", "value2" };
}
// GET api/values/5
[Route("{id:int}")]
[Route, MapToApiVersion( "1.0" )]
public string Get(int id)
{
return id.ToString();
}
}
[RoutePrefix("api/v{version:apiVersion}/values")]
[ApiVersion( "2.0" )]
public class ValuesControllerV2 : ValuesController
{
// GET api/values/5
[Route("{id:int}")]
[Route, MapToApiVersion( "2.0" )]
public string Get(int id)
{
return id.ToString();
}
}V1接口(使用ValuesController)定义了两个接口函数Get和Get(ById)。但是V2应用程序接口ValuesControllerV2虽然覆盖了Get(ById),但它必须重新实现或调用Get的基本方法,以使Get应用程序接口在v2上可用。
有没有一种更好的策略,我们不必为API升级中保持不变的所有函数重新实现或编写传递。
发布于 2018-03-26 09:27:58
首先,我建议评估您的版本控制策略。大多数服务作者(和/或公司)定义了类似N-2的策略。这将帮助您确定这个问题有多大,或者它是否根本就是一个问题。
你可以使用继承,但也有龙。在Web API中,您需要执行其他操作才能使其正常工作。内置实现不支持继承的RoutePrefixAttribute或RouteAttribute.您还应该考虑不能取消继承操作。如果你日落了一个API,这会使你的策略变得非常混乱。并非所有版本控制方案都是向后兼容或前滚的。
我强烈建议您将业务逻辑放在服务之外。通用基类非操作方法或扩展方法可以帮助减少重复代码。如果每个操作的实现都很小,并且您有一个已建立的版本控制策略,那么复制就不是问题了。
任何一种方法或两者的组合都应该提供足够的灵活性。
https://stackoverflow.com/questions/47202945
复制相似问题