在什么情况下使用特定于供应商的API是合理的？

Question

我正在使用Websphere Portal和Oracle。上周两次，我发现编写特定解决方案的最直接方法是使用IBM和Oracle提供的API。但是，我意识到使用这些供应商API编写的每一行代码都会让我们更加关注这些系统（特别是我们最近才实现的门户网站）。

您如何确定使用供应商API的好处是否超过了绑定（绑定？束缚？F？Pin？Pin？）特定产品的成本？

Answer 1

显然是一个非常个人/具体的问题......

但要记住的一件事是，你可以通过包装提供给你自己定义的API 的专有API来抵消“被囚禁”的风险。这样，您不仅可以将自己的代码与第三方API分离，而且还可以通过将第三方API简化为您想要的最小功能集来更轻松地编写自己的逻辑。然而，这种极简主义方法带来的风险很小，有时您可能会“错过”第三方库/ API提供的一些很酷的功能。

Answer 2

如果其他供应商可能使用不同的API提供类似的功能，您可以为操作定义自己的界面，并创建特定于供应商的实现。这有助于您避免锁定。

这是否值得取决于几个因素：应用程序代码将取决于API的数量，API的复杂程度（以及它将需要的包装程序），您切换供应商的可能性。

Answer 3

与自定义/特定于供应商的API紧密绑定的成本效益比会有很大差异，具体取决于您正在使用的内容以及将使用您的产品的人员。供应商锁定可能是某些客户的障碍，可能会被其他客户忽视。也许您在决定做什么时可能会发现这些指南很有用：

1. 如果你的产品只针对某个特定的公司而且他们已经绑定了一些技术堆栈，因为他们有合同让他们付出巨大的代价来获得支持，而且他们无法在近期或远期将其改变堆叠，你应该锁定。
2. 如果您的产品针对的是同一行业中的各种公司，并且您确认其中大多数公司都拥有相同类型的系统，那么您可以暂时锁定，因为它更快或更容易，以后您可能会适应你的代码是少数人
3. 如果您针对广泛的客户，请尽量避免锁定。但是，如果您注意到这些将在您的产品上市时间中发挥重要作用，您可以再次将它们用于您的第一批客户，然后根据其他客户的需求进行调整，但仅限于他们来。

Answer 4

这是一个非常主观的问题。我的看法是，如果您使用的是甲骨文，并且没有立即离开甲骨文的计划，我就不会想到一个很好的理由来否定供应商提供的API的强大功能和灵活性。将您的应用程序抽象到N度以追求一些可移植性的圣杯通常会导致比其价值更多的麻烦，并且肯定会增加您的成本。它还可能导致性能低于最佳。甚至TSQL也得到了每个数据库供应商的增强和调整，以至于您可能会在某个时候在查询中使用某些专有扩展;也许你可以获得所有的好处。