(Теперь, когда я привлек ваше внимание к аббревиатурам...)
Может быть, лучше задать вопрос так: Когда следует использовать DTO и когда POCO в сети потока данных TPL? (Потому что лучший выбор может зависеть от обстоятельств).
Я сделал это обоими способами, и я не уверен, когда использовать один против другого. Должна ли логика обработки находиться в блоке (то есть лямбда, которую вы передаете стандартным блокам) или она должна быть, как обычно, инкапсулирована в объект?
(Напоминаем, что такое DTO и POCO обсуждается в этом вопросе POCO и DTO.)
Я склоняюсь примерно на 70% к DTO, текущим в сети, потому что:
Моя мысленная модель при проектировании/кодировании сети потоков данных концентрируется на многоступенчатом конвейере преобразования — данные снова и снова преобразуются и преобразуются. Основное внимание уделяется преобразованиям, а не «поведению» каждого вида элемента данных. Я хочу видеть преобразования в виде набора (относительно) небольших функций (лямбд), которые я могу просматривать вместе.
Элементы в потоке обычно не являются экземплярами классов модели для приложения, обычно это просто экземпляры, которые создаются в потоке и уничтожаются в конце потока. (Иногда они живут достаточно долго, чтобы перейти из одного блока в другой.)
С другой стороны:
Иногда вы можете думать об элементах данных как о претерпевающих последовательные преобразования, которые будут влиять на классы данных, инкапсулирующие поведение.
Если вы инкапсулируете поведение в классах данных, то создание блоков потока данных и их подключение становятся шаблонными (поскольку в лямбда-выражениях блока не выполняется конкретная работа с данными), и, таким образом, вы можете создавать довольно общие компоновщики, которые легко описывают построение любой сети.
(Единственное, в чем я относительно уверен, так это в том, что стили не должны смешиваться в одной сети.)
Но у меня недостаточно разнообразного опыта, чтобы сформулировать какие-то ориентиры, чтобы подсказать, как выбрать. Я ищу такие рекомендации или аргументы за/против для рассмотрения.