(Now that I have your attention with acronyms ...)
Maybe a better way to ask the question is: When should you use DTOs and when POCOs in a TPL Dataflow network? (Because the better choice may depend on circumstances).
I've done it both ways and I'm unsure of when to use one vs. the other. Should the processing logic be in the block (i.e., the lambda you pass to the standard blocks) or should it be encapsulated, as per usual, in the object?
(As a reminder, what DTOs and POCOs are is discussed in this POCO vs DTO question.)
I lean about 70% towards DTOs flowing in the network because:
My mental model, when designing/coding a dataflow network, is concentrating on a multi-stage transformation pipeline - data gets transformed and transformed again and then again. The focus is on the transformations, not on the "behavior" of each kind of data item. I want to see the transforms laid out as a bunch of (relatively) small functions (lambdas) that I can browse together.
The items in the flow aren't usually instances of model classes for the application, they're usually just instances that are created within the flow and destroyed by the end of the flow. (Sometimes they live only long enough to pass from one block to the other.)
On the other hand:
You could sometimes think of the data items as undergoing successive transforms, which would weigh towards the data classes encapsulating behavior.
If you do encapsulate behavior in the data classes then creating the dataflow blocks and hooking them up becomes boilerplate (since there is no data specific work done in the block's lambdas) and thus you can create rather generic builders that easily describe building any network.
(The only thing I'm relatively sure of is that the styles shouldn't be mixed in one network.)
But I don't have enough varied experience to be able to formulate any guidelines to suggest how to choose. I'm looking for such guidelines, or pro/con arguments to consider.
