Должны ли элементы, передаваемые в сети потока данных TPL, быть DTO или POCO?

(Теперь, когда я привлек ваше внимание к аббревиатурам...)

Может быть, лучше задать вопрос так: Когда следует использовать DTO и когда POCO в сети потока данных TPL? (Потому что лучший выбор может зависеть от обстоятельств).

Я сделал это обоими способами, и я не уверен, когда использовать один против другого. Должна ли логика обработки находиться в блоке (то есть лямбда, которую вы передаете стандартным блокам) или она должна быть, как обычно, инкапсулирована в объект?

(Напоминаем, что такое DTO и POCO обсуждается в этом вопросе POCO и DTO.)

Я склоняюсь примерно на 70% к DTO, текущим в сети, потому что:

  • Моя мысленная модель при проектировании/кодировании сети потоков данных концентрируется на многоступенчатом конвейере преобразования — данные снова и снова преобразуются и преобразуются. Основное внимание уделяется преобразованиям, а не «поведению» каждого вида элемента данных. Я хочу видеть преобразования в виде набора (относительно) небольших функций (лямбд), которые я могу просматривать вместе.

  • Элементы в потоке обычно не являются экземплярами классов модели для приложения, обычно это просто экземпляры, которые создаются в потоке и уничтожаются в конце потока. (Иногда они живут достаточно долго, чтобы перейти из одного блока в другой.)

С другой стороны:

  • Иногда вы можете думать об элементах данных как о претерпевающих последовательные преобразования, которые будут влиять на классы данных, инкапсулирующие поведение.

  • Если вы инкапсулируете поведение в классах данных, то создание блоков потока данных и их подключение становятся шаблонными (поскольку в лямбда-выражениях блока не выполняется конкретная работа с данными), и, таким образом, вы можете создавать довольно общие компоновщики, которые легко описывают построение любой сети.

(Единственное, в чем я относительно уверен, так это в том, что стили не должны смешиваться в одной сети.)

Но у меня недостаточно разнообразного опыта, чтобы сформулировать какие-то ориентиры, чтобы подсказать, как выбрать. Я ищу такие рекомендации или аргументы за/против для рассмотрения.


person davidbak    schedule 28.06.2014    source источник


Ответы (2)


Это зависит от того, какую обработку вы выполняете, и я не думаю, что TDF как-то повлияет на это решение.

Если операция, которую вы выполняете, действительно является «методом» элемента (например, Eat для Hamster), тогда используйте логику самого элемента. Если, с другой стороны, между элементом и процессом нет реальной связи (например, ведение журнала), а элемент просто «проходит через» блок, тогда используйте логику метода блока.

person i3arnon    schedule 28.06.2014

Каким должен быть базовый класс токенов Petri Net?

Каким должен быть базовый класс узлов объектов в диаграммах активности UML?

Любой класс подойдет

Хотя ваш вопрос длинный, для меня он относится к той же категории вопросов/ответов.

person xmojmr    schedule 30.06.2014