不确定我在PHP AJAX中使用的是什么开发模式

$req = $_REQUEST['type'];
if($req == 'get_users'){
// do stuff
}

我知道HTML/CSS显然是View，但有时，我会让PHP生成HTML元素。

视图实际上应该是包含表示逻辑的实例。他们从模型层获取信息，并根据这些信息决定向用户发送什么响应。响应可以只是一个HTTP头，也可以是一个HTML文档，该视图由多个模板组合而成。

那么，PHP可以生成"View"元素这一事实会改变它在编程模式中的角色吗？

这涉及到一个主题，即您不能实现经典MVC（如smalltalk所定义的），因为视图应该观察模型的变化。这对于web来说是非常难以实现的，非常不切实际，而且无法扩展。。完全相反，对于web，我们倾向于使用Model2MVC、MVP和MVVM模式，它们的灵感来自于最初的MVC。还有HMVC模式，它实际上和MVC无关，但试图解决相同的问题。

所有这些受MVC启发的模式在实现表示层的方式上都有所不同，而表示层也是视图的所在。在Model2MVC模式中，您有一个活动视图，它从模型层请求信息。在MVP和MVVM中，视图是被动的，并且通过类似控制器的结构接收数据。

大多数函数都是数据库写入和读取。这是控制器，我说得对吗？

如果我理解你的意思，那么：不，不是真的。

在所有受MVC启发的模式中，控制器或类似控制器的结构主要负责改变模型层和视图的状态。在MVP和MVVM中，它还从模型层请求数据，在MVVM中甚至对其进行操作

但与存储（可能是SQL数据库，也可能不是SQL数据库）的交互隐藏在模型层的深处。我写了一篇关于这个主题的较长的帖子。

我假设模型是我定期调用的函数和类的集合？

不完全正确。请参阅上面的链接。

我是否遵循编程模式？

如果没有代码，很难说，但我很有信心，你不会严格遵循任何MVC启发的设计模式。您正在做的是实现某种形式的SoC，这是MVC的核心原则。我想说，您正处于PHP开发人员真正开始研究OOP原理和模式以进行进一步改进的阶段。

大多数函数都是数据库写入和读取。这是控制器，我说得对吗？

如果是：

1. 根据URL决定如何处理请求，那么它就完成了控制器的角色
2. 与数据库交互，应用业务逻辑并返回一些数据，然后它就完成了模型的角色
3. 使用这些数据生成HTML/JON/XML/发送给客户端的任何其他内容，那么它就完成了视图的角色

如果它正在做上述多项工作，那么它就是不同角色的大杂烩，你应该考虑将你的担忧分离出来。

我假设模型是我定期调用的函数和类的集合？

模型是与数据交互并强制执行业务逻辑的代码。

我的主要问题是，一种编程模式是否可以应用于多种编程语言，即使一种是客户端，另一种是服务器端。

是的。

您可以使用客户端JavaScript来编辑DOM（视图），根据用户输入决定要做什么（控制器），并使用XMLHttpRequest从服务器获取数据（模型）。

然后，您可以使用PHP为该JS（View）生成JSON，根据JS（Controller）请求中的数据设置要做什么，并与数据库交互以获取响应（Model）的数据。

我是否遵循编程模式？

听起来你可能在遵循上帝的反模式，但你只简要概述了你正在做的事情。

I mean, PHP is technically a server-side language right?

是的，对。（尽管它可以在本地使用，但它甚至可以被编译以生成桌面应用程序二进制文件等。）

So does the fact that PHP can generate "View" elements change its role in the programming pattern?

没有。"视图"的核心概念是其与应用程序其他部分的分离。理想情况下，在"视图"层中不会有任何业务逻辑、数据库查询等。例如：首先，进行所有的计算和运算。作为最后一步，您可以将结果转换为用于输出的"视图"（如HTML、XML或JSON…）。您不会将"echo"语句和SQL查询混合在一起。

Do I have it right that this is the controller?

在您的描述中，我们有两个不同的东西：一个可以称为"路由器"——它是您根据HTTP请求确定调用哪个函数/方法的地方。

在这种情况下，"控制器"将是那些函数，它们依次调用数据库读/写函数和视图构建函数。控制器与模型交互，并传递输出。它是应该与数据库交互的模型。

I am assuming that the model is the set of functions and classes I call periodically?

模型通常是读取和写入数据库的一组函数。这是现实世界中的主要用法。但这不是"模型"的定义——这只是它最常见的形式

例如：如果你有一个虚拟商店，它销售产品。然后，您将有一个"产品"模型，即一个类，用于处理将新产品插入数据库、更新产品信息、计算价格以及您可能想在"产品"中做的所有其他事情。这些方法必须在任何控制器、任何路线、任何视图中工作——这是模式分离/职责组织的目标之一。您应该能够使用相同的商店模型创建一个全新的前端网站。

whether or not a programming pattern can apply to more than one programming language even though one is client-side and another is server-side.

是的。我们在一个应用程序中使用许多不同的语言：HTML、JavaScript、PHP、SQL等。整个应用程序可以遵循一组模式。每种语言都可以用于执行模式中的一个或多个角色。

Am I even following a programming pattern? If I am not or am somewhat close to one, does it matter if I am not following a pattern exactly?

是，你是。我认为，即使你没有它的名字，即使你遵循"你自己的模式"，你也肯定遵循了一些模式，否则你将无法构建你的应用程序。这种模式可以是MVC、ABC、XYZ、CSM或其他任何模式。当然，如果您学习了这些概念，您就可以与使用这些概念的其他开发人员讨论您的应用程序代码。学习当然是件好事，但是。。。

否，如果您没有完全遵循某个模式，则"无关紧要"。您最终可能会创建一个新的、增强的、更好的模式！有时，为了适应某些模式而担心可能会破坏你的创造力。不要过分担心。

尽管如此，我认为你做得对，想知道、理解甚至掌握这些模式及其概念。MVC对于程序员来说是一件很重要的事情。一个好老师可以帮助你。阅读漂亮的书和文章。SO的问答。谷歌的一些研究。。。最重要的是，还有编码经验。如果你有一个实用的目标要实现，有一个应用程序要编码，并在实践中应用你学到的东西，你就会逐渐理解它们。