Это общий шаблон дизайна?

Question

Я использую следующий шаблон/стиль в своих приложениях/программах и хочу знать, является ли это общей моделью, которую я не знаю.

Когда я должен написать приложение, подобное большой функции, которая получает входные данные из разных источников, обрабатывает и создает выход. Как и модель IPO (вход-процесс-вывод).

У меня есть один класс/тип, который представляет только мое состояние/данные, которые не имеют логики. Большую часть времени я называю его Контекст, ExecutionContext или RuntimeContext. У меня также есть несколько классов/типов, которые содержат только логические функции без учета состояния (в статических методах C# в статических классах). После моей начальной точки приложения я сначала создаю контекст и использую его в качестве аргументов для своих функций. Контекст содержит состояние жалобы/данные приложения, а все мои статические функции/методы манипулируют контекстом. В конце цепочки функций и выполнения вызова/выполнения, и контекст содержит конечное состояние, если мне нужны выходные данные.

Я пытаюсь создать картину, визуализировать этот подход

Преимущества этих картины

1. я могу простой тест моей логика (небольшие кусочки статических функций) с unittest
2. не так сложно использовать параллельный код (только для контекста нужен потоковый код)
3. зависимости от других систем, в основном разделенных как абстракции (интерфейсы) в контексте (например, IDbContext). Это упрощает испытания большого пространства

И вот теперь мой вопрос. Это общий шаблон? Когда да, как это называется?

Спасибо за каждый намек! :)

С уважением

Answer 1

Это выглядит как Dataflow.

Функции - это черные ящики, которые действуют на предоставленные ему данные. Потоки данных завершены и могут даже моделировать традиционные императивные структуры управления потоком.

Answer 2

Когда вы выдаете запрос на ASP.NET MVC, то есть запись, и в конце концов возвращает вывод. ASP.NET MVC является открытым исходным кодом, и есть тонны диаграмм, которые объясняют весь трубопровод и как он работает. Он также очень настраиваемый, поэтому разработчики могут подключать свои собственные классы, перехватывать определенные события, перехватывать определенные части (фильтры, аутентификацию, авторизацию и т. Д.).

Если бы я был вами, я бы начал изучать это и заимствовать некоторые идеи из Это. Вам не нужно смотреть исходный код. Вы можете начать с просмотра диаграмм для конвейера и посмотреть, что он делает и как он это делает.

Теперь ваш код - это просто функции, которые выполняются последовательным образом. Если вы хотите использовать Ориентацию объектов, используйте интерфейсы и разрешите настройку, перехват событий, перехват и т. Д., Тогда это будет сложно.

Here - это диаграмма на случай, если вы заинтересованы.

Answer 3

Хорошо, это распространено в приложениях в стиле IoC, где службы/репозитории являются одиночными и, следовательно, безстоящими.

Преимущество этого подхода заключается в том, что он экономит много памяти и некоторое время (нет необходимости в создании новых экземпляров компонентов).Недостатком является то, что вы как-то теряете ООП, а также трудно поддерживать большую картинку без поддержки сильных интерфейсов и контейнера для инъекций IoC/Dependency.

Также рассмотрите механизм ThreadLocal<> в .NET. Таким образом, вам не нужно передавать свой контекст явным, а не доступ к глобальной переменной переменной, содержащей ее (но тогда - вам нужно следить, когда ветвящиеся потоки, другая тема, которую обрабатывает IoC/DI).