ASP.NET WebAPI - 如何为多个服务创建抽象层
ASP.NET WebAPI - how to create an abstract layer for multiple services
好吧,假设我正在制作一个精美的网上商店。
我有一个支付提供商(比如 paypal),它要求用户登录 paypal 网站,确认凭据,然后将他重定向到我的网站。
所以基本上背后的代码如下所示:
class PaymentManager
{
public string AcceptPayment(Payment payment)
{
//return redirect url
}
public bool ConfirmPayment(string paymentToken)
{
//if token is valid the payment succeded
}
}
所以基本上这个管理器的使用从我的控制器映射到 2 个控制器方法(每个都需要一个单独的请求)。
现在,假设我有一个不同的支付管理器,它需要顺序执行 3 个方法而不是 2 个。类似于:
class AnotherPaymentManager
{
public string AcceptPayment(Payment payment)
{
//return validation redirect url
}
public string ValidatePayment(string validationCode)
{
//return redirect url
}
public bool ConfirmPayment(string paymentToken)
{
//if token is valid, confirm payment
}
}
现在这个class'用法映射到3个控制器方法(我们需要客户端执行Accept
方法来声明支付,然后执行Validate
方法来验证它最后执行 Confirm
方法以确保服务器已接受它)。
问题是:假设这些管理者有不同的API使用场景来做同样的事情(如上所示),有没有办法做一个抽象它们和控制器之间的层?我的意思是:
interface IPaymentManager
{
void MakePayment(); //this controls the payment methods flow
//Something like (Accept -> Confirm) in the former case
//and (Accept -> Validate -> Confirm) in the latter
}
我在 ASP.NET WebAPI 2 中这样做,但我认为它也适用于 MVC。
如果我理解正确,当用户创建交易时,他们将被重定向到支付提供商(响应中有重定向 url)。到达那里后,他们会确认他们的凭据 returns 他们到您喜欢的网上商店(使用支付提供商提供的确认令牌)。如果该令牌有效,则交易成功。此外,这些操作中的每一个都需要在您的控制器中有一个单独的端点。
如果这些假设是正确的,我会说没有必要,甚至不建议在这里创建抽象。还有来自支付提供商的响应数据(validationCode、paymentToken 等),您的 PaymentManger 函数和控制器端点依赖这些提供商才能继续该过程。
根据我的经验,过早尝试抽象化会给你带来更多的工作。如果没有更多信息(支付提供商客户端的更多实现),您可能会进行过于具体的抽象 - 这不能用于您稍后添加的不同 PaymentManager 类型。
但是,如果你已经拥有这些数据(validationCode等),那么你可以在这里进行抽象,但我仍然认为这是不必要的,并且可能会浪费时间。
如果你决心在这里抽象,那么你可以在你的每个PaymentManager中实现你的接口类。让每个 PaymentManger 实现 MakePayment 函数,该函数将调用相应的 PaymentManager 函数。
同样,我不建议在这里进行抽象。这没有意义,在我看来真的不会有帮助。等到你再实现几个 PaymentManager 类。然后您将能够更准确地看到不同类型的 PaymentMangers 之间的模式并将这些模式抽象出来。
如果我对问题的理解不正确,请让我知道我对问题的理解有误,我会尝试再次回答。
附带说明一下,如果您还没有并且正在调用外部 API.
,我建议您查看 asynchronous functions and the await operator
希望对您有所帮助。
好吧,假设我正在制作一个精美的网上商店。
我有一个支付提供商(比如 paypal),它要求用户登录 paypal 网站,确认凭据,然后将他重定向到我的网站。
所以基本上背后的代码如下所示:
class PaymentManager
{
public string AcceptPayment(Payment payment)
{
//return redirect url
}
public bool ConfirmPayment(string paymentToken)
{
//if token is valid the payment succeded
}
}
所以基本上这个管理器的使用从我的控制器映射到 2 个控制器方法(每个都需要一个单独的请求)。
现在,假设我有一个不同的支付管理器,它需要顺序执行 3 个方法而不是 2 个。类似于:
class AnotherPaymentManager
{
public string AcceptPayment(Payment payment)
{
//return validation redirect url
}
public string ValidatePayment(string validationCode)
{
//return redirect url
}
public bool ConfirmPayment(string paymentToken)
{
//if token is valid, confirm payment
}
}
现在这个class'用法映射到3个控制器方法(我们需要客户端执行Accept
方法来声明支付,然后执行Validate
方法来验证它最后执行 Confirm
方法以确保服务器已接受它)。
问题是:假设这些管理者有不同的API使用场景来做同样的事情(如上所示),有没有办法做一个抽象它们和控制器之间的层?我的意思是:
interface IPaymentManager
{
void MakePayment(); //this controls the payment methods flow
//Something like (Accept -> Confirm) in the former case
//and (Accept -> Validate -> Confirm) in the latter
}
我在 ASP.NET WebAPI 2 中这样做,但我认为它也适用于 MVC。
如果我理解正确,当用户创建交易时,他们将被重定向到支付提供商(响应中有重定向 url)。到达那里后,他们会确认他们的凭据 returns 他们到您喜欢的网上商店(使用支付提供商提供的确认令牌)。如果该令牌有效,则交易成功。此外,这些操作中的每一个都需要在您的控制器中有一个单独的端点。
如果这些假设是正确的,我会说没有必要,甚至不建议在这里创建抽象。还有来自支付提供商的响应数据(validationCode、paymentToken 等),您的 PaymentManger 函数和控制器端点依赖这些提供商才能继续该过程。
根据我的经验,过早尝试抽象化会给你带来更多的工作。如果没有更多信息(支付提供商客户端的更多实现),您可能会进行过于具体的抽象 - 这不能用于您稍后添加的不同 PaymentManager 类型。
但是,如果你已经拥有这些数据(validationCode等),那么你可以在这里进行抽象,但我仍然认为这是不必要的,并且可能会浪费时间。
如果你决心在这里抽象,那么你可以在你的每个PaymentManager中实现你的接口类。让每个 PaymentManger 实现 MakePayment 函数,该函数将调用相应的 PaymentManager 函数。
同样,我不建议在这里进行抽象。这没有意义,在我看来真的不会有帮助。等到你再实现几个 PaymentManager 类。然后您将能够更准确地看到不同类型的 PaymentMangers 之间的模式并将这些模式抽象出来。
如果我对问题的理解不正确,请让我知道我对问题的理解有误,我会尝试再次回答。
附带说明一下,如果您还没有并且正在调用外部 API.
,我建议您查看 asynchronous functions and the await operator希望对您有所帮助。