数据处理的设计模式？（MVC 替代方案）答案

【问题标题】：Design Pattern for Data Processing? (MVC alternative)数据处理的设计模式？（MVC 替代方案）
【发布时间】：2011-01-15 01:52:55
【问题描述】：

作为一名 PHP/Web 开发人员，我是 MVC（模型-视图-控制器）的忠实粉丝。我喜欢在坚实的基础上构建一个应用程序，该应用程序明确地将业务逻辑、表示逻辑和控制流分开。

但是，我在仅服务器端的应用程序上也做了很多工作，这些应用程序仅处理数据并记录过程和任何相关结果（例如导入脚本、数据迁移脚本、Web 服务、TCP 套接字服务器、等等）。在这些情况下，不需要大型花哨的 MVC 框架。

我意识到在这里仍然可以应用 MVC，但它似乎有点矫枉过正。除了原始的过程方法或类对象的随机混搭之外，是否有任何特定的架构设计模式特别适合数据处理、一次性运行和服务器守护程序类型的应用程序？

【问题讨论】：

en.wikipedia.org/wiki/Architectural_pattern_(computer_science) 可能会有所帮助。
改用en.wikipedia.org/wiki/…。 Wikipedia 链接包括对 SO 和其他一些东西造成严重破坏的括号，因此它们应该被 URI 编码为 %28 和 %29。
模式（大多数时候）与语言无关，但我很确定大多数构建这些类型的应用程序的人不会在 PHP 中这样做。框架是旨在解决特定范式中问题的库的集合。您可以通过询问以下内容来获得更准确的问题答复：数据处理编程的设计模式和框架。
你说得对，PHP 与问题无关，我正在寻找一种与语言无关的架构模式。

【解决方案1】：

如果我理解正确，您所说的应用程序没有 shell 命令行之外的用户界面。如果是这种情况，您仍然可以在软件架构级别使用 MVC - 您的视图将变得微不足道。你的控制器同样是微不足道的，因为在模型和视图之间传播的动作非常少。

当然，对于微不足道的 View 和 Controller，它可能根本就不是任何模式。我认为这没有问题（在您所说的级别上）。关键是采用基于接口的方法（就像使用 MVC 一样），这最终会提供更好的设计；如果将来需要，它可以很容易地适应不同的用户界面或调用方式。

【讨论】：

谢谢史蒂文，这是个好建议。
特别是，您很好地说明了 MVC 的范围具有高度适应性。
顺便说一句——您是否碰巧对如何按照您的建议实现“基于接口的方法”有任何具体想法，假设我想避免精简 MVC 设计但想组织我的纯过程代码好一点？
你的意思有多具体？特定于语言、面向对象或特定于程序？或者只是一些特定的设计方法？在一般层面上（适用于我所知道的任何语言或范式），我的想法归结为：（1）确保您了解代码中每个组件的职责和知识； (2) 对依赖关系过于迂腐。如果有足够的时间，我发现这两个想法会梳理出好的设计——特别是会推动基于接口的方法（因为职责和依赖关系是设计中接口功能的核心）。

【解决方案2】：

我想你需要先问问自己你想解决什么问题（你正在寻找这些模式）

一旦你知道了这一点，你可能会在这里找到一些有用的东西：

【讨论】：

【解决方案3】：

由于它与数据处理相关，我假设您有某种数据存储，您可以查看存储库和 DTO（数据传输对象）架构模式。

更一般地说，GoF 目录中的一些设计模式也适合您，例如用于一次性运行的 Singleton、用于抽象处理逻辑的 Facade、用于不同处理逻辑的策略、可能用于守护进程的状态机

【讨论】：