已知.Net项目的API策略

Question

我正在为我的应用程序编写一个API并且有一些未解决的问题（考虑到版本控制）。

• 用户应该直接调用我的对象还是需要提供一些抽象？
• 用户使用API​​的X版编写的代码是否仅适用于版本X，或者它是否也适用于最新版本？

最初我认为“抽象”和“最新”。但是.Net（或Silverlight）例如公开具体类，包含所有以前的版本，并且2.0 dll也将使用2.0 CLR运行，即使安装了4.0。

我正在寻找已知.Net项目（客户端应用程序）的API策略示例。例如NUnit和NHibernate，但你知道的任何其他库都很棒。

Answer 1

就个人而言，我没有太多理由将额外的抽象放在适当的位置，至少在.NET中是这样。在.NET中，use abstract classes instead of interfaces通常更好，更容易，可能使用工厂方法。这可以让用户直接使用（似乎是）您的对象，但仍然为您提供干净的版本支持。

至于您的API的未来验证 - 如果您遵循Design Guidelines for Designing Class Libraries，您更有可能自然地创建一个向前兼容的API。许多设计指南（例如优选抽象类，使用未密封的类等）自然会导致designing for extensibility，其中包括您在未来版本中的可扩展性。

除非有充分理由避免这种情况，否则我倾向于选择允许将来进行API验证 - 它往往是一个（小）更多的工作，但后来降低了维护成本，特别是因为它有助于避免版本控制等部署问题

大多数.NET项目，包括您列出的项目，都倾向于采用这种方法。通常，破解API只能在“主要”版本上完成，即使这样，它仍然保持在最低限度。如果您在每个版本上将用户锁定到当前的API中，那么您就有动力让他们不升级到您的最新版本 - 这与预期动机相反，因为这会增加您的支持需求（您必须支持更多，旧版本），并防止用户使用您最新和最好的功能。

Answer 2

我认为这两个答案都取决于您的必需品，而且必须重要：业务限制。

• 抽象与否？这取决于消费者是否有理由使用对象本身，或者更重要的是，如果允许用户这样做。如果用户可以使用它们（以业务逻辑方式），则公开类。

另外请记住，不必外部化所有对象的功能，您可以使用“friend”修饰符保留类的内部使用属性，甚至是DLL的属性：{{ 3}}

实施例。您正在为银行设计API，并希望让您的消费者使用“客户”类，但您确实不希望他们调用Client.GetTotalBalance（）。

考虑到这一点，你可以非常安全地将对象外部化，如果你保持私密，私密; .NET非常强大。

• 前向兼容性？您应该始终尝试以允许扩展的方式设计API，确保使用强命名约定，以便您可以根据需要保留方法的名称，按此顺序，您将保证旧代码运行时更新的版本，即使它没有消耗所有可用的新资源。

但这并不意味着，如果需要，你不能采取方法，特别是如果涉及安全风险。

希望有帮助：）。

另外两件事：正如“Reed Copsey”建议的那样，请看一下：http://msdn.microsoft.com/en-us/library/08w05ey2.aspx。

我想建议，如果您从头开始并且有时间为您的课程实现序列化，那么根据您的API使用情况，它可能非常方便：http://msdn.microsoft.com/en-us/library/ms229042.aspx