在当前客户端，架构师坚持使用XmlSerializer及其相关属性将对象模型序列化为XML，这最终将构成文件格式的基础。
我对这种方法已经死了。请记住，这个客户的工作人员不是高技能的开发人员，而且承包商专门用于实施最佳实践和设计原则，因为它是一个绿地实施。我一直在努力构建论证，直到我决定回到基本原则，即SOLID。
原因1：XmlSerializer违反单一责任原则
当我为对象模型（即类Person）创建模型对象时，我可以按如下方式描述该类：
Person类描述系统中Person的属性和属性。
添加XmlSerializer属性后，说明将变为：
Person类描述系统和中Person的属性和属性 这些属性和属性如何序列化为XML。
请注意和。因此，违反单一责任原则。
原因2：从长远来看，XmlSerializer导致违反接口隔离原则的类
由于这是一种文件格式，随着时间的推移保证的一件事就是文件格式发生变化并且迁移需要发生 - XmlSerializer在说出一个XML模式（基于它和##）方面是非常顽固的39; s属性）就是这样。添加ObsoleteAnnotation等属性虽然不会阻止普通开发人员使用该特定属性，但会阻止XmlSerializer将值序列化为/从该属性（基本上就像事实上的XmlIgnoreAttribute ！）。
这是XmlReader甚至LINQ-to-XML序列化实施在长期维护/增强方面为开发人员节省大量精力的地方，尽管最初的开发工作并保持接口隔离原则因为XmlSerializer强制开发人员在他们不使用的类接口中保留属性/属性，以便从一种版本的文件格式迁移到另一种版本。
注意：我并不是说使用XmlSerializer到处都是 一定是糟糕的设计（ SRP 参数适用于所有实现），仅适用于接口正在发生变化的情况，即文件格式。
严格遵守SOLID原则应用于不断变化的文件格式并使用XmlSerializer作为序列化技术 - 我对SOLID原则应用的分析是否正确？
答案 0 :(得分：1)
由于您正在阅读书籍，我可以向您推荐The Pragmatic Programmer。这本书完全是关于实用而不是教条。
将属性放在类文件中以支持序列化是一种实用方法，因为其他方法，无论其感知的好处如何，总体上往往会有更多的缺点。更难理解，更难维护等等。