【发布时间】:2015-02-09 19:18:32
【问题描述】:
在当前的客户中,架构师坚持使用XmlSerializer 及其相关属性将对象模型序列化为 XML,这最终将形成文件格式的基础。
我坚决反对这种方法。请记住,该客户的员工不是高技能的开发人员,并且承包商是专门为实施最佳实践和设计原则而引入的,因为它是一个全新的实施。我一直在努力构建论点,直到我决定回到基本原则,即 SOLID。
原因一:XmlSerializer 违反了单一职责原则
当我为我的对象模型(即类 Person)创建模型对象时,我可以如下描述该类:
Person 类描述系统中 Person 的属性和属性。
添加XmlSerializer 属性后,描述变为:
Person 类描述系统中 Person 的属性和属性和 这些属性和属性如何序列化为 XML。
注意和。因此,违反了单一职责原则。
原因 2:从长远来看,XmlSerializer 会导致类违反接口隔离原则
由于这是一种文件格式,随着时间的推移,可以保证的一件事是文件格式会发生变化和迁移 - XmlSerializer 非常顽固,因为它使用一种 XML 模式(基于它的属性)并且这就对了。添加像ObsoleteAnnotation 这样的属性虽然它不会阻止普通开发人员使用该特定属性,但确实会阻止XmlSerializer 将值序列化到/从该属性(基本上就像事实上的XmlIgnoreAttribute!)。
这是XmlReader 甚至LINQ-to-XML 序列化实现将在长期维护/增强方面为开发人员节省大量精力的地方,尽管最初的开发工作很努力并保持接口隔离原则 因为XmlSerializer 强制开发人员将属性/属性保留在他们不使用的类接口中,以便从一种文件格式版本迁移到另一种版本。
注意:我并不是说在任何地方都使用XmlSerializer是一定是糟糕的设计(尽管 SRP 论点适用于所有实现),仅在接口发生变化的情况下,即文件格式。
严格遵守SOLID原则应用于变化的文件格式并使用XmlSerializer作为序列化技术——我对SOLID原则应用的分析是否正确?
【问题讨论】:
-
欢迎来到现实 :) 大型软件供应商还有很多其他违反良好编程原则的例子。
-
我不确定您对答案的期望,因为您在问题中基本上表明它确实违反了 SOLID 的某些原则。我只能说不要把 SOLID 当作教条来对待。如果您开始编写
IMath接口和包装对象以将System.Math注入到您的对象中,那么您已经走得太远了。 -
如果您正在为纯度而战,请考虑使用 DTO 进行序列化,以使模型遵循您想要的所有原则。但是,请注意,DTO 违反的甚至更多,你已经列出了...... :) 现实更复杂,所有这些 SOLID、SRP 等等。事实上,这就是项目架构师存在的原因——他们负责将理论(如设计模式或原则)应用于实践。
-
@Dirk 好吧,答案可能是在这个特定应用程序中使用
XmlSerializer的论据,为什么在这种情况下它会是好的设计?我不将 SOLID 视为教条,但由于过去的经验,我试图合理化“XmlSerializer bad”的直觉反应。架构师还高度重视 SOLID,这就是为什么以这些术语表达论点的原因。
标签: c# xmlserializer solid-principles