Диаграмма ниже показывает, как
- производитель создает новые сообщения / запросы, заполняющие данные членов,
- сообщения сериализуются,
- отправлено потребителю,
- dserialized
- Потребитель вызывает виртуальную функцию - использует полиморфное поведение ссылки на базовый класс.
В этой статье обсуждается аналогичный вопрос.
Но мне нужно отделить DTO (в DataContract.DLL) и некоторую реализацию (App.EXE), связанную с этим DTO, в рамках одной иерархии классов (я стараюсь избегать введения другого семейства классов, таких как RequestProcessors).
Реализация должна быть переопределена в другой сборке, чем в dll, с определением DTO / сообщения - этот dll должен быть легковесным - используется разными командами. Поэтому я не могу ссылаться на производный класс в атрибуте [KnownType(typeof(SomeData))], как в упомянутой статье. Я не хочу включать реализацию метода в DataContract.DLL.
Как реализовать полиморфизм в иерархии с сериализованными классами (сообщениями DataContract), где DataContracts и реализация разделены в разных сборках? Возможно ли это?
Я не нашел пути, но C # не является моим основным языком. Я вижу, что производитель не должен зависеть от Consumer.EXE, но должен создавать наиболее производный класс. Итак, все классы должны быть введены в DataContracts.DLL. Частичное определение класса, скорее всего, не является перекрестной сборкой.
Может быть, будет работать сборка из нескольких файлов? Может быть, метод расширения в ближайшем приближении.
Обновлено ( цитата из статьи ):
DTO, которые оформлены как классы DataContract, являются реальными объектами. В них могут быть методы, но методы не являются частью процесса сериализации
