想象一组代表一些 API 的库。通过使用控制机制的反转,具体的实现将被注入到一个消费项目中。
这是一种情况。我有一些 API 库依赖于某些功能的其他 API 库 - 因此 API 库本身在某些时候是耦合的。这种耦合以后可能会成为一个问题,因为改变一个API会导致依赖的API发生变化,相应的实现也需要改变,所以最坏的情况是我们最终需要相当多的项目修改以反映仅其中一个的变化形式。
现在我想到了两种可能的解决方案:
创建一个统一相关 API 库的单体 API 项目。
通过使每个库为依赖于其他 API 的所有功能提供接口来进一步解耦 API ,从而消除直接依赖关系。这可能会导致两个库中的代码相似,但可以自由选择通过 IoC 机制选择的实现,还允许 API 彼此独立改进(当 API 发生更改时,更改将仅影响其实现库,而不影响其他 API 或其实现)。
第二种方法的问题是代码重复,结果可能是需要引用的 api 库过多(例如,在 .NET 应用程序中,每个 API 将是一个单独的 DLL。在某些情况下,例如 Silverlight应用程序,这可能是应用程序大小的问题 - 下载时间和客户端整体性能)。
有没有更好的解决方案。什么时候将一些 API 库合并成一个更大的库更好,什么时候不合并?我知道这是我要问的一个非常普遍的问题,但是让我们暂时忽略到期日期、估计、客户要求和技术,我希望能够基于实现最大可扩展性和最短维护时间来确定正确的方法。那么,选择这两种方法或您可能建议我的另一种方法的充分理由是什么?
编辑:
我觉得我必须澄清一下这个问题。我考虑将 API 彼此分离,而不是将 API 与其实现分离。因此,例如,如果我有用于验证访问权限的安全 API,以及使用(引用)安全 API 的用户帐户 API,则更改安全 API 将需要更改用户帐户 API 以及它们的实现。以这种方式耦合的 API 越多,必须应用的更改就越多。这是我想要避免的。