C# 反序列化接口对象

我在上一个项目中尝试了坚实的体系结构

我有一个名为ILog的接口和一个实现ILog的类LOG。根据我的理解，应该遵循开放/封闭原则

为了保持对扩展的开放性，我通过列表实现了前端，而不是使用公司实现列表

序列化列表没有问题，但反序列化是有问题的。我当然理解为什么，因为反序列化程序不知道应该使用哪个实现类

问题: 如何知道将通过接口引用序列化的对象反序列化为哪种具体类型

序列化列表没有问题，但反序列化是有问题的

如果您正在进行反序列化，那么您必然需要以某种方式与序列化程序通信，该序列化程序包含要使用的接口的表示形式。对于Json.NET，您还可以使用see或与依赖注入结合使用

问题：如果我必须为数据存储/数据导入定义特定的实现类，那么使用List有什么帮助

接口将代码与实际实现分离，从而带来各种好处。例如，在单元测试方面，它们使模拟更容易，因为您可以使用模拟实例来满足接口，而不是被迫使用真实的类。此外，接口还允许您从中受益，这是C语言中的类所不具备的。要进一步了解接口的好处，请查看问题的各种答案或参阅博客文章

如上所述，接口总是会引入一定程度的开销/抽象，您需要根据每个案例/情况进行评估，无论它们是否合理

处理接口对象的数据存储的最佳方法是什么？或者它们仅在运行时使用

---

您必须存储具体的表示，这意味着在持久化时，您需要决定使用哪个具体的实现来存储和以后的反序列化。

像SOLID这样的指南如果不能满足您的需要，对您没有好处。要回答的问题不是你是否遵循了坚实的原则；这取决于您是否真的需要ILog接口。为什么要序列化记录器？或者更一般地说，为什么要使用想要反序列化某些内容的接口？你不能将序列化的FooFrobber反序列化为BarFrobber，即使它们都实现了IFrobber。我认为这可能是一个好主意，因为这个项目将持续一段时间。为什么不要求ILog的实现者也实现反序列化呢？毕竟，他们最了解自己的impl。可扩展性、接口和序列化不必相互关联。请提出一个非常具体的问题，因为这听起来太模糊了。例如，如果您的问题是如何知道将通过接口引用序列化的对象反序列化为哪个具体类型，那么答案可能是在序列化时将类型信息与之一起保存。