Php 需要一些关于MVC分离的建议吗

我应该注意我使用的是Zend框架。虽然这不会影响具体的答案，但它确实意味着我可以在几个地方实现我的以下方法（动作助手、控制器等）

问题是我有buildOptions（）和parseOptions（）方法，它根据“标记”接受$\u GET/$\u POST变量，并生成规则，然后在select查询中使用这些规则。例如？modelSort=id&modelOrder=asc

上面提到的“model”显然与特定的模型有关，它被用作“tag”，因此我可以使用model2Sort和model2Order，这样参数之间就没有冲突

然而，我现在遇到的问题是，这些方法应该去哪里？它们通常处理请求参数。我已经读了很多关于胖模型、瘦控制器的书。这应该是一个抽象模型。我的想法是，如果是的话，我会这样做：

（注意，我知道我不会像这样直接调用。方法将由子类使用）

$abstractModel->buildOptions（$params）

其中“params”可以是任何参数，如请求参数$\u GET或$\u POST：

$abstractModel->buildOptions（$\u-GET）

现在，从我所看到的，模型不是天生处理请求变量，而是传递给方法的参数

建议？这个方法属于哪里？模型，控制器

特别是在Zend上，它应该是抽象模型中的动作助手、插件吗

---

谢谢你的建议

我喜欢这样想

Controller:
  Collect user input
  Sanitize input
  Instantiate model
  model->doStuff( cleaned user input )
  Instantitate view
  view->buildPrettyHtml( model )

---

嗯，有两种不同的方式来查看MVC。您可以执行控制器推送（控制器将数据推送到视图中）或视图拉送（视图从模型中拉取所需的数据）。这两种方法各有优缺点。但共同的主题是模型对用户输入不敏感。你应该询问用户的要求。这使得在不同的视图中重用模型方法变得更加容易（如果需要的话）

我个人喜欢View Pull方法，因为它允许您轻松地重用视图（因为您不需要担心需要将哪些数据推入视图）。因此，控制器应该处理非显示用户交互（更新表等）。但是视图应该负责与显示相关的用户交互。因此，如果您购买这种方法，排序和分页应该由视图读取，并且视图的工作是告诉模型有关它的信息。我喜欢保持我的模型相当轻，以便它们尽可能重复使用

但重要的不是你把它放在哪里。这是关于一致性。只要您在应用程序中对分隔线保持一致，就不会有问题。问题在于，一半的时间你在一个地方做，另一半时间你在另一个地方做。因此，选择一种方法，并坚持下去

与大多数这种性质的事情一样，这在很大程度上取决于个人偏好和个人经验。没有单一的最佳方法（如果有，我们都会这么做）。了解每种方法的优点和缺点，然后自己选择（这样你就能理解你所做的事情的原因和反对理由）

---

祝你好运……

你想得太多了。只是别忘了方法的安全性。阻止我添加我自己的键和值，这听起来像是你的方法做不到的。我不认为我想得太多了。我认为如果我选择一种方法而不是另一种方法，我可能会导致很多问题。据我所知，模型不处理请求对象。。我的方法不是具体的，它目前所做的并不重要。我只是提供了一些细节来说明一个用例。可以将此问题应用于任何处理请求参数的方法，这些参数应提供给select查询。我想我已经多次遇到相同的问题/疑问。然而，直到今天，我还不太了解“胖模型瘦控制器”方法，我在这里读了一点-Imho，当我在多个控制器操作中有类似的请求处理时，我只是创建了一个控制器操作帮助器，并在这些操作开始时这样调用它：$this->u helper->parseRequestParams（$this->getRequest（）->getPost（））；如果有更多具有类似请求参数处理的操作，我可能会将其从操作帮助器移动到控制器插件。@Richard：因此，为什么会有选项。出于好奇，你为什么更喜欢它？事实上，这并没有充分的理由。我一直使用控制器推送，我只知道另一种方式（视图推送），所以它非常主观。我已经习惯了我的做事方式（在控制器操作中设置所有视图数据）。除非我能看到一些真正的好处，否则我不认为我会改变。我必须说，我更喜欢控制器推送。但是谢谢你给我介绍了看待MVC的新方法！