适当的 API 设计以实现版本无关？
我继承了大约 200 个项目的庞大 .NET 解决方案。现在有一些开发人员希望开始将自己的组件添加到我们的应用程序中，这将要求我们开始通过 API 公开功能。
当然，主要问题是我们手上的解决方案包含如此庞大的依赖关系，我们必须小心避免每次应用程序中的某个地方发生微小变化时都会破坏 API。我们还希望能够在不破坏任何以前的第三方应用程序的情况下逐步公开新功能。
我有办法解决这个问题，但我不确定这是理想的方法 - 我正在寻找其他想法。
我的计划是基本上拥有三个 dll。
- APIServer_1_0.dll - 这将是具有所有依赖项的 dll。
- APIClient_1_0.dll - 这将是我们的开发人员实际引用的 dll。我们的解决方案中没有提及任何混乱的内容。
- APISupport_1_0.dll - 这将包含允许客户端动态加载“服务器”组件并执行所需任何功能的接口。上述两个 dll 都依赖于此。这将是“客户端”部分引用的唯一 dll。
我最初采用这种设计是因为我们在 Windows 服务之间进行进程间通信的方式有点相似（除了客户端通过命名管道与服务器通信，而不是动态加载 dll）。
虽然我相当确定我可以完成这项工作，但我很想知道是否有更好的方法来完成相同的任务。
I've inherited an enormous .NET solution of about 200 projects. There are now some developers who wish to start adding their own components into our application, which will require that we begin exposing functionality via an API.
The major problem with that, of course, is that the solution we've got on our hands contains such a spider web of dependencies that we have to be careful to avoid sabotaging the API every time there's a minor change somewhere in the app. We'd also like to be able to incrementally expose new functionality without destroying any previous third party apps.
I have a way to solve this problem, but i'm not sure it's the ideal way - i was looking for other ideas.
My plan would be to essentially have three dlls.
- APIServer_1_0.dll - this would be the dll with all of the dependencies.
- APIClient_1_0.dll - this would be the dll our developers would actual refer to. No references to any of the mess in our solution.
- APISupport_1_0.dll - this would contain the interfaces which would allow the client piece to dynamically load the "server" component and perform whatever functions are required. Both of the above dlls would depend upon this. It would be the only dll that the "client" piece refers to.
I initially arrived at this design, because the way in which we do inter process communication between windows services is sort of similar (except that the client talks to the server via named pipes, rather than dynamically loading dlls).
While i'm fairly certain i can make this work, i'm curious to know if there are better ways to accomplish the same task.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您可能希望查看 Microsoft 托管加载项框架 [MAF] 和托管可扩展性框架 [MEF]（链接由 Kent Boogaart 提供）。 正如 Kent 所说，前者与组件的隔离有关，而后者主要关注可扩展性。
最后，即使您不利用其中任何一个，有关 API 版本控制的一些概念也非常有用 - 即版本控制接口，然后通过适配器提供版本间支持。
也许有点矫枉过正，但绝对值得一看！
希望这有帮助！ :)
You may wish to take a look at Microsoft Managed Add-in Framework [MAF] and Managed Extensibiility Framework [MEF] (links courtesy of Kent Boogaart). As Kent states, the former is concerned with isolation of components, and the latter is primarily concerned with extensibility.
In the end, even if you do not leverage either, some of the concepts regarding API versioning are very useful - ie versioning interfaces, and then providing inter-version support through adapters.
Perhaps a little overkill, but definitely worth a look!
Hope this helps! :)
为什么不直接使用 .NET 中内置的程序集版本控制？
添加对程序集的引用时，请务必选中引用上的“需要特定版本”复选框。这样您就可以准确地知道在任何给定时间您正在使用哪个版本的程序集。
Why not just use the Assembly versioning built into .NET?
When you add a reference to an assembly, just be sure to check the 'Require specific version' checkbox on the reference. That way you know exactly which version of the Assembly you are using at any given time.