我们有一个需要公开API的桌面应用程序。
有人说：API应该有一个抽象层，因此在未来的版本中实际的实现可能会发生变化。
其他人说：API应该是特定于版本的。因此，使用版本X的API只能使用它。版本X + 1还将部署版本X的dll，以免破坏现有用法。据称，这与.Net或Silverlight等框架的工作方式是一致的。
您有什么看法？
答案 0 :(得分：2)
您应该考虑的一些问题：
我的意见是，如果可能的话，您应该在版本之间保持API兼容性。微软已经实现了它，主要是使用Office，这就是为什么有很多附加组件，附件和LOB应用程序围绕它们构建的原因。例如，我在Access XP上编写了一个应用程序，该应用程序使用了Excel自动化，并且它在Office 2010中无错误。这就是我所说的兼容性！
答案 1 :(得分：1)
我发现对界面进行版本控制是实现重大变更的有用工具。
您应该尽力在第一时间使用您的API接口。
当您进行重大更改（更改现有签名，因此必须重新编译客户端代码）时，您必须更改界面，并且在执行此操作时可以更改版本。如果您可以避免，那么不间断的更改（例如，将新功能添加到其他类）不应更改版本。
答案 2 :(得分：1)
使用关闭进行修改，打开扩展的想法。如果可能的话，您公开的API的任何部分都不应在将来的版本中更改。 （如果它们的功能相同，则可以修改未曝光的部件）。程序员希望使用API并使代码在其生命周期内工作，而不必担心他引用的版本。
考虑到在API的更高版本中，您可能会公开API的每个用户可能想要采用的新功能 - 但他已经有针对旧版API编写的代码。他应该能够在不重写旧代码的情况下插入新部件（假设新部件不依赖于重大变化）。
如果要进行重大更改，则不应删除旧方法，而应将其标记为[Obsolete]，并明确说明应如何更新到新API。
答案 3 :(得分：0)
如果您使用Net作为参考，您应该注意到他们采用混合方法，他们使用两者，不要将CLR版本与NET版本混淆。
您应该考虑使用您的应用，以便为您找到答案。
我的资金用于尽可能保持所有版本的API兼容性。
但也有缺点。
此致
答案 4 :(得分：0)
如果您决定采用特定版本，请确保您与用户保持联系。我错过了最后期限六次，我的供应商在不通知我的情况下改变他们的网络服务，不得不争先恐后地提出解决方案