这是一种常见的设计模式吗？

Question

我在我的应用程序/程序中使用了以下模式/样式，并想知道这是否是我不了解的常见模式。

当我必须编写一个类似于从不同来源获取输入数据的大型函数的应用程序时，请执行处理并创建输出。像IPO模型（输入过程输出）。

我有一个类/类型，它只代表我没有逻辑的状态/数据。大多数时候我将其命名为Context，ExecutionContext或RuntimeContext。我还有多个类/类型，它们只包含逻辑作为无状态函数（在静态类中的C＃静态方法中）。在我的app入口点之后，我首先创建了上下文，然后使用它作为我的函数的参数。上下文保存app的complate状态/数据，所有我的静态函数/方法都操纵上下文。在函数链的末尾，调用/执行完成，如果我需要outputdata，则上下文保持最终状态。

我尝试创建一幅可视化这些方法的图片

这些模式的优点是

1. 我可以简单地测试我的逻辑（小块静态函数） 单元测试
2. 使用并发代码并不困难（只有上下文需要线程安全代码）
3. 与其他系统的依赖关系在上下文中作为抽象（接口）主要解耦（例如IDbContext）。这使得更大范围的测试变得简单

以下是我的问题。这是一种常见的模式吗？是的，怎么称呼？

感谢您的每一个提示！ :)

问候

Answer 1

当您向ASP.NET MVC发出请求时，它有一个条目，最后它返回一个输出。 ASP.NET MVC是开源的，有大量的图解释整个管道及其工作原理。它也是非常可定制的，因此开发人员可以插入自己的类，拦截某些事件，挂钩到某些部分（过滤器，身份验证，授权等）。

如果我是你，我会开始研究并从中借鉴一些想法。您不必查看源代码。您可以从查看管道的图表开始，看看它在做什么以及它是如何做的。

现在你的代码只是以串行方式执行的函数。如果你想使用面向对象，利用接口并允许自定义，事件拦截，挂钩等，那么这将是困难的。

Here是您感兴趣的图表。

Answer 2

嗯，这在IoC风格的应用程序中很常见，其中服务/存储库是单例，因此是无状态的。

这种方法的优点是它可以节省大量内存和一些时间（不需要生成新的组件实例）。缺点是如果没有强大的接口支持和IoC / Dependency Injection容器，你会以某种方式失去OOP aproach并且难以维护更大的图片。

另外看看ThreadLocal<>机制构建到.NET中 - 这样你就不需要显式传递你的上下文了，而是需要访问包含它的thred-scoped全局变量（但是 - 你需要注意分支线程时，IoC / DI处理的另一个主题。

Answer 3

这看起来像Dataflow。

这些功能是黑盒子，它们对提供给它的数据起作用。数据流完整，甚至可以模拟传统的命令式流控制结构。