0

Diagram below depicts how

  • producer creates new messages/requests filling data members,
  • messages are serialized,
  • sent to consumer,
  • dserialized,
  • Consumer invokes virtual function - uses polymorphic behavior of base class reference.

This article discusses a similar question.
But I need to separate DTO (in DataContract.DLL) and some implementation (App.EXE) linked to this DTO within the same class hierarchy (I try to avoid introducing another family of classes like RequestProcessors).
Implementation should be overridden in a different assembly than dll with definition of DTO/message - this dll should be lightweight - used by different teams. Therefore I can't refer to derived class in attribute [KnownType(typeof(SomeData))] like in mentioned article. I don't want to include method implementation in DataContract.DLL.

How to implement polymorphism in hierarchy with serialised classes (DataContract messages) where DataContracts and implementation are separated in different assemblies? Is it possible?

I didn't find the way but C# is not my primary language. I see that producer should not depend on Consumer.EXE but should create most derived class. So, all classes should be introduced in DataContracts.DLL. Partial class definition likely are not cross assembly.

Maybe multiple file assembly will work? Maybe extension method are closest approximation.

Updated (quotation from article):

DTOs that are decorated as DataContract classes are real objects. They can have methods in them, but the methods are not part of the serialization process

enter image description here

Vlad
  • 1,977
  • 19
  • 44

1 Answers1

0

How to implement polymorphism in hierarchy with serialised classes (DataContract messages)

"Polymorphic data contract " is an oxymoron.

Data contracts are DTOs (Data Transfer Objects) implementation for WCF.
WCF clearly separates data (data contracts, DTOs) from behavior (services).

Do not mix them.

In other words:

  • don't try to implement polymorphism in DTO hierarchy;
  • do not add any behavior to DTOs.

I try to avoid introducing another family of classes like RequestProcessors

But you shouldn't!

This is natural approach for service-based solutions, and this is not about WCF (SOAP) only. E.g., REST (ASP .NET Web API in case of .NET) does the same.

Moreover, service-based way suits well for business-logic implementation inside applications, because it perfectly fits Dependency Injection containers.

Do implement some IRequestProcessor hierarchy - this is the right way to go.

Note, that linked question is about inheritance, but it is not about behavior inheritance. IMO, term "polymorphism" is misused there. You can (and often should) derive one data contract from another, but you can (should) derive data, not behavior.

Dennis
  • 37,026
  • 10
  • 82
  • 150
  • https://stackoverflow.com/questions/3734160/adding-methods-to-datacontract-objects-for-wcf – Vlad Jul 06 '18 at 07:08
  • I use async communication (queue). WCF, etc, any form of web services are unnecessary duplicate in my case. – Vlad Jul 06 '18 at 07:11
  • So what? :) "Are DataContracts in WCF nothing more than DTOs" - yes, they are. They *can* have behavior, technically, because there are no behavior-less entities in .NET (DTO's are represented by `class`es, and there's no any `message`s). But they really shouldn't. – Dennis Jul 06 '18 at 07:13
  • I agree that DataContracts are not good for this case. They just way of serialization that was used in solution. Indeed the goal of solution is to use polymorphic behavior of single hierarchy but with necessity to serialize **somehow** objects for IPC. This is not dispute about pure OOD - I just will be thankful to obtain implementation in particular language – Vlad Jul 06 '18 at 07:27
  • Agnostic to messaging technology (WCF, AMQP, etc, therefore technology is not mentioned) – Vlad Jul 06 '18 at 07:34
  • @Kaponir: why single hierarchy is a requirement? What bad thing will happen, when there will be hierarchy of "request processors" or similar? – Dennis Jul 06 '18 at 07:37
  • The same reason why polymorphism is beneficial - there are lots of different types of messages are expected and the simplest and less error prone way to process request is to override its own Process method. – Vlad Jul 06 '18 at 20:36