CoreWCF中的XmlAttributeHolder类清理优化分析

背景介绍

在CoreWCF项目的1.7.0版本中，XmlAttributeHolder类作为一个公共类存在于CoreWCF.Channels命名空间下。这个类最初是为了支持WebHttp功能而创建的，但随着时间的推移，开发团队发现它实际上更适合作为内部实现细节，而不应该暴露为公共API。

问题分析

XmlAttributeHolder类目前存在的主要问题是其可见性设计不够合理。作为一个辅助类，它被不必要地暴露在公共API中，这带来了几个潜在问题：

1. API污染：增加了公共API的复杂度，可能误导开发者使用本不该公开的内部类
2. 维护负担：作为公共API，任何修改都需要考虑向后兼容性
3. 设计原则违背：违反了最小公开原则，即只暴露必要的API

解决方案探讨

针对这个问题，开发团队提出了三种可能的解决方案：

方案一：代码复制到WebHttp项目

将XmlAttributeHolder的实现复制到WebHttp项目中，使其成为该项目的内部实现。这种方案的优点是：

• 完全解耦，WebHttp项目自包含所需功能
• 避免跨项目依赖
• 可以针对WebHttp需求进行定制化修改

缺点是可能存在代码重复，如果未来其他模块也需要类似功能。

方案二：创建CoreWCF.Internals共享包

建立一个专门用于存放内部共享代码的CoreWCF.Internals包。这种方案的优点是：

• 集中管理共享代码
• 避免重复实现
• 保持公共API的整洁

缺点是需要额外维护一个包，增加了项目结构的复杂度。

方案三：维持现状但添加文档

最简单但最不推荐的做法，仅通过文档说明这个类不应该被外部使用。这种方案实际上没有解决问题，只是缓解症状。

技术实现建议

从技术实现角度看，方案一和方案二都值得考虑。对于短期解决方案，方案一更为简单直接；从长期架构规划来看，方案二可能更优。

如果采用方案一，需要注意：

1. 确保复制后的类有适当的访问修饰符（internal）
2. 考虑是否需要对原始实现进行任何调整
3. 更新相关引用点

如果考虑方案二，需要规划：

1. 共享包的版本管理策略
2. 依赖关系管理
3. 内部API的设计规范

最佳实践

无论采用哪种方案，都应该：

1. 将emptyArray字段改为internal，这是最低限度的改进
2. 在移除或移动公共类时，考虑使用[Obsolete]属性标记过渡期
3. 确保相关测试覆盖所有修改点
4. 更新项目文档说明这些变更

总结

CoreWCF项目中XmlAttributeHolder类的清理工作虽然看起来是一个小问题，但它反映了API设计中的重要原则。合理的API边界划分对于长期维护性和用户体验至关重要。开发团队对这个问题的讨论体现了对代码质量的重视，通过这样的持续优化，可以保持代码库的整洁和可维护性。