因此，我负责采用我们拥有源代码的活跃第三方产品，并进行专有更改，这将破坏与该产品 future 更新的兼容性。这个产品布局得很好，但它是一个企业应用程序，从数据库一直到用户界面，所以我不能只做一些简单的事情，比如添加一个专有的业务层来隐藏和扩展第三方应用程序并编写我自己的应用程序用户界面。因为用户界面是我们最初购买的产品的很大一部分。
所以我正在寻找的是一些指南、最佳实践、注意事项等。在我承担这项任务时要牢记在心。
我计划做的唯一真正可靠的事情是。
- 保留产品的所有扩展 在我自己的文件中，或者像这样隔离 可能的。 (不过，我想听听您对此的任何策略或恐怖故事)
- 注释对现有方法的任何更改，以便它们 是 可搜索，并且有良好的符号 改变的方式和原因 制作，这样当我合并更新时，我可以轻松浏览我的更改列表，并进行所需的任何修改。
除此之外，我只是计划将装饰器、外观、代理和适配器模式保留在手边，并尝试在未来尽可能轻松地实现这一点。
欢迎任何意见，谢谢。
最佳答案
在您的应用程序核心中，为第三方产品提供的任何服务定义一个接口(interface)。
在您的基础设施层中，将每个接口(interface)实现为第三方产品的适配器/包装器。
针对应用程序中其他位置的接口(interface)进行编码。使用控制反转来注册服务接口(interface)的实现，并按接口(interface)类型和上下文自动解析配置的实现。我最喜欢的 IoC 库是 StructureMap .
结果，
为适应第三方产品 future 版本的更改，您必须进行的唯一更改将隔离到您的基础设施层。应用程序中其他地方对服务的每次引用都只依赖于应用程序核心。即使您完全放弃该第三方产品而转而采用替代实现，您唯一需要更改的部分就是使用 IoC 容器注册服务实现。 (许多工具通过命名和继承约定来解决实现问题，从而自动执行此任务)
关于.net - 寻找最佳实践。扩展第三方产品以尽可能轻松地合并新版本有哪些注意事项，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/6615372/