在mvc Web应用程序中，我的控制器在这些场景中会是什么？

Question

1）您网站的主页在哪里适合“控制器”？我见过有些人使用“页面”控制器处理静态页面，如，关于，家庭，联系等，但对我来说这似乎不是一个好主意。为您的主页创建一个独特的控制器是一个更好的选择吗？毕竟，它可能需要访问多个模型，而且根据某些人使用的模型理论，整个控制器并不能很好地流动。

2）如果您需要一个用于多种类型用户的仪表板，那么这将是一个仪表板控制器，它可以根据哪个用户切换代码，或者您是否会在每个用户的每个控制器中说出仪表板操作？例如，admin / dashboard，account / dashboard等

3）在我看来，使用整个简单的CRUD示例在尝试解释控制器时就像一个魅力，但是一旦你通过这些简单的功能，它就会崩溃并导致你的控制器变得笨拙。当其他人在用户控制器中创建登录功能时，为什么有些人会选择创建登录控制器？我认为的一个原因是我们很多人来自页面方法背景，并且很难将控制器视为“对象”。或“名词”或“名词”因为页面并不总是这样。举个例子，为什么你想创建一个“页面”？控制器，它可以处理真正与彼此无关的页面，只是为了拥有一个“容器”。适应行动。对我来说似乎不对。

4）控制器是否应该与用例有关，而不是“对象”。可以执行哪些操作？出于所有密集目的，您可以创建一个用户控制器来执行整个应用程序中的每个操作。或者，您可以根据“关注区域”创建控制器。有些人喜欢说。或者，如果需要，您可以为每个视图创建一个控制器。有太多的余地使得很难找到一致的使用方法。

控制者可能不应该这么混乱，但出于某种原因，他们会让我感到困惑。任何有用的评论将不胜感激。

Answer 1

1）我为我的一些MVC使用了一组简单的自制类，它将控制器名称与动作和视图名称联系起来（它是一种前端控制器风格，类似于Zend）。对于通用网站，我们假设它有一个主页，隐私政策，联系页面和一个关于页面。我真的不想为所有这些事情制作单独的控制器，所以我将它们放在我的 IndexController 中，其函数名称如 actionIndex（）， actionPrivacy（）， actionContact（）和 actionAbout（）。

与此同时，在我的Views目录中，我有一个与每个动作关联的模板目录。默认情况下，任何操作都会自动查找关联的模板，但您可以根据需要指定一个模板。所以 actionPrivacy（）会在 index / privacy.php 中寻找模板文件， actionContact（）会查找 index / contact .php 等。

当然，这也与URL有关。因此，访问 http://www.example.com/index/about 的网址会运行 actionAbout（），这会加载“关于”网页模板。由于about页面是完全静态的内容，我的 actionAbout（）除了为前端控制器提供公共操作以查看和运行之外什么都不做。

所以为了回答你问题的核心，我确实放了多个“页面”。到一个控制器，它适用于我的目的。每个控制器的一个模型是我认为在使用Web MVC时我不会尝试遵循的理论，因为它似乎更适合状态更好的应用程序。

2）为此，我会有多个控制器。按照我上面使用的相同方法，我会按照你的建议使用 / admin / dashboard 和 / account / dashboard ，尽管他们没有理由不能使用相同的方法（或部分相同的模板。

我想如果我拥有大量不同类型的用户，我会使事情变得更通用，只使用一个控制器，并且有一个mod_rewrite规则来处理加载。这可能取决于仪表板在功能上的复杂程度，以及设置的帐户是什么样的。

3）我发现CRUD功能很难直接实现到MVC的任何层，并且仍然保持干净，灵活和高效。我喜欢将CRUD功能抽象到任何对象可能调用的服务层，并且有一个基础对象类，我可以从中扩展任何需要CRUD的对象。

我建议使用一些PHP ORM框架来进行CRUD。他们可以消除很多实现良好的麻烦。

就登录控制器与用户控制器而言，我认为这取决于您的应用程序域。根据我的编程风格，我倾向于想到“登录”。作为用户模型域内的简单操作，因此在用户控制器内具有单个操作。更准确地说，我会让 UserController 实例化用户模型并在模型上调用登录例程。我不能告诉你这是正确的方法，因为我无法确定应该采用什么样的正确方法。这是一个背景问题。

4）你对这个余地是正确的。您可以轻松创建一个控制器来处理您的应用程序/站点想要执行的所有操作。但是，我认为你会同意这会成为维护的噩梦。我仍然在考虑我在市场研究公司的最后一份工作，其中内部PHP应用程序是由海外团队完成的，我只能假设几乎没有培训。我们正在讨论处理整个网站的10,000行脚本。这是不可能的。

所以，我建议你休息一下