构建第三方API / SDK

Question

概述

• 在过去的3年里，我们用C＃
构建了一个功能齐全的软件包
• 我们的软件以这样的方式构建，即处理应用程序所需的大量低级管道，以便我们的开发人员可以专注于他们试图解决的特定问题，而不是所有的细节。这显着改善了开发和发布时间
• 因此，代码被分解为各种项目，以便我们进行逻辑分离（例如，前端MVC应用程序，服务层，核心框架层等）
• 我们的核心框架项目内置了很多功能（应用程序的主要内容），并且已经仔细地组织成各种熟悉的名称空间（例如数据访问，IO，日志记录，邮件）等）
• 正如我们最初构建的那样，我们的目标始终是让我们的团队成为目标受众，我们的开发人员编写各种新功能并根据需要添加到框架中。

挑战

• 现在，老板希望能够将我们的代码库打开到我们公司以外的第三方开发人员和团队。这些第三方人员需要能够直接进入我们的核心库并构建他们自己的模块，这些模块将与我们的服务器一起部署。由于应用程序的性质，我们可以通过REST或SOAP或类似的方式向它们公开功能来解决它​​们，它们需要在类似于我们自己的环境中工作，它们可以针对我们的核心库进行开发并编译他们自己的发布DLL
• 这引发了许多关于知识产权的问题和挑战（我们必须能够保护我们的代码的内部工作），分发，部署，版本控制和测试和发布，也许最重要的是我们如何将框架塑造成最能满足这些需求。

您会提供什么建议？你会怎么做？您希望改变什么样的东西或者您希望采用何种设计方法？我意识到这些问题是非常开放的，甚至可能含糊不清，但我主要是寻找任何可能面临类似挑战的人提供的建议，资源/教程或故事。谢谢！

Answer 1

我不确定MEF的答案是否能真正解决您的问题。即使使用Interfaces和MEF将实现与合同分开，您仍然需要提供实现（因为我理解您的问题），因此，MEF不会让您不必使用IP来交付程序集。< / p>

最重要的是，如果您需要分发实施程序集，这些第三方将拥有您的IP，并且能够对其进行反编译。我没有办法解决.NET的问题，最后我查了一下。您可以使用obfuscation使其变得更加困难，但这不会阻止某人反编译您的实现，只是让您更难阅读和理解。

正如您所指出的，最好的方法是将实现置于SaaS类型的边界之后，但听起来似乎是不可能的。

我要补充的是，我强烈建议开发一个强大的版本控制模型。这将影响您定义接口/ API的方式，如何随时更改它们以及如何对程序集进行版本化。如果你不小心，并且你没有对你的程序集使用AssemblyVersion和AssemblyFileVersion的组合，你将强制从API客户端进行不必要的重新编译，这可能是一个巨大的麻烦（遗憾的是，甚至一些大型控制供应商都没有处理这个问题。 Read up on these，因为我认为它们对API /组件供应商非常重要。

NDAs和/或许可协议是另一种方式，正如@trailmax所示，如果您认为您的用户会尊重此类协议（个人与公司可能会以不同方式查看这些类型的协议）。

哦，还要确保你Sign your Assemblies有一个强名。要做到这一点，您可能需要制定一个策略来保护您的签名密钥。这一开始看起来很简单，但充分保护您的签名密钥并不像第一次看到的那样容易。您经常需要为不同的环境提供多组密钥，需要将密钥合并到CI / CD系统中，并且需要确保对发布密钥的访问保持紧密。

Answer 2

正如@HighCore已经说过的那样，为你想要公开的所有东西实现接口。将它们放入单独的项目/存储库中，并提供对项目/存储库的只读访问权限。但是你的接口必须正确记录，否则对其他人来说可能会很痛苦。

这样，您的代码对他们来说并不是真正可见的，他们仍然可以使用它。

如果不能解决问题，并且您被迫向他们展示您的代码，请让他们签署NDA。 NDA应声明您的代码是您的代码，并且不能以任何方式重新分发它。

我想我的答案与问题一样模糊，但会给你一些想法。