php - 在这些情况下，我的 Controller 在MVC Web应用程序中将是什么？

Question

1)您网站的首页在哪里适合“ Controller ”？我已经看到有人使用“页面” Controller 来处理静态页面，例如，关于，家庭，联系人等，但是对我来说，这似乎不是一个好主意。为您的首页创建一个独特的 Controller 会是更好的选择吗？毕竟，它可能需要访问多个模型，但实际上并不能很好地顺畅运行，某些人使用的每个模型理论都只能使用一个 Controller 。

2)如果您需要一个仪表板用于多种类型的用户，那将是一个仪表板 Controller ，它会根据哪个用户切换代码，或者您会说每个用户在每个 Controller 中的仪表板 Action ？例如，管理员/仪表板，帐户/仪表板等。

3)在我看来，在尝试解释 Controller 时，使用整个简单的CRUD示例就像一个魅力，但是一旦您跳过了这些简单的功能，它就会崩溃，并且可能导致您的 Controller 笨拙。当其他人在用户 Controller 中执行登录功能时，为什么有些人选择创建登录 Controller ？我认为的一个原因是，我们很多人来自页面处理背景，很难将 Controller 视为“对象”或“名词”，因为页面并非总是以这种方式工作。举例说明为什么您要创建一个“页面” Controller 来处理实际上彼此无关的页面，而只是拥有一个“容器”来容纳 Action 。只是对我而言似乎不合适。

4) Controller 是否应该比用例具有更多的用例，而不是可以对其执行操作的“对象”？出于所有密集的目的，您可以创建一个用户 Controller ，该用户 Controller 在整个应用程序中执行所有操作。或者，您可以像某些人所说的那样为每个“关注区域”创建一个 Controller 。或者，您可以根据需要为每个 View 创建一个 Controller 。有太多的回旋余地，以致于很难找出一种一致的使用方法。

Controller 可能不会造成这种困惑，但是由于某些原因，它们会让我感到困惑。任何有用的评论将不胜感激。

Answer 1

1)我为我的一些MVC东西使用了一个简单的自制类集，并将 Controller 名称与 Action 和 View 名称相关联(这是Front Controller样式，类似于Zend)。对于一个通用网站，我们假设它具有一个主页，隐私策略，联系页面和一个关于页面。我并不是真的想为所有这些事情创建单独的 Controller ，所以我将它们放在IndexController中，并使用actionIndex()，actionPrivacy()，actionContact()和actionAbout()这样的函数名。

要做到这一点，在我的Views目录中，我有一个与每个 Action 相关的模板目录。默认情况下，任何操作都会自动查找关联的模板，尽管您可以根据需要指定一个模板。因此actionPrivacy()将在index/privacy.php处查找模板文件，actionContact()将在index/contact.php中查找模板，等等。

当然，这也与URL有关。因此，命中http://www.example.com/index/about的网址将运行actionAbout()，这将加载“关于”页面模板。由于About页面是完全静态的内容，所以我的actionAbout()绝对不执行任何操作，除了为Front Controller提供查看和运行的公共(public)操作之外。

因此，为了回答您问题的核心，我确实将多个“页面”放入单个 Controller 中，并且可以很好地达到我的目的。每个 Controller 一个模型都是一种理论，我认为在使用Web MVC时我不会尝试遵循，因为它似乎可以更好地适应具有状态的应用程序。

2)为此，我将有多个 Controller 。按照我上面使用的相同方法，我将按照您的建议使用/admin/dashboard和/account/dashboard，尽管没有理由他们不能使用相同(或相同部分)模板。

我想，如果我拥有大量不同种类的用户，我将使事情变得更通用，并且仅使用一个 Controller ，并具有mod_rewrite规则来处理加载。这可能取决于仪表板在功能上的复杂程度以及帐户的设置。

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

我建议将某些PHP ORM框架用于CRUD。他们可以消除获得良好实现的许多麻烦。

就登录 Controller 与用户 Controller 而言，我想这取决于您的应用程序域。按照我的编程风格，我倾向于将“登录”视为用户模型域内的一个简单操作，因此在用户 Controller 中对其具有单个操作。更准确地说，我将使用UserController实例化用户模型并在该模型上调用登录例程。我不能告诉你这是正确的方法，因为我不能肯定地说正确的方法应该是什么。这是上下文的问题。

4)你说得对。您可以轻松地创建一个 Controller 来处理您的应用程序/网站想要做的所有事情。但是，我认为您会同意这将成为维护的噩梦。我仍然想起我在市场研究公司的最后一份工作，这时内部的PHP应用程序是由一个海外团队完成的，我只能假定几乎没有培训。我们正在谈论处理整个网站的10,000个行脚本。这是不可能维持的。

因此，我建议您将应用程序/站点分割为业务领域，并基于此创建 Controller 。弄清楚应用程序的核心概念，然后从那里开始。

例子

假设我有一个有关海牛的网站，因为海牛显然很摇摇欲坠。我想要一些普通的网站页面(关于，联系方式等)，用户帐户管理，论坛，图片库，以及研究文档的资料区域(有关海牛的最新科学知识)。非常简单，很多都是静态的，但是您可以开始查看细目。
IndexController-处理有关页面，隐私策略，常规静态内容的信息。
UserController-处理帐户创建，登录/注销，首选项
PictureController-显示图片，处理上传
ForumController-可能不多，我会尝试集成一个外部论坛，这意味着我在这里不需要太多功能。
LibraryController-显示最近新闻和研究的列表
HugAManateeController-通过HTTP实时拥抱的虚拟海牛

这可能至少给了您基本的分离。如果发现 Controller 变得非常大，可能是时候将业务领域分解为单独的 Controller 了。

每个项目都会有所不同，因此只需进行一点规划就可以使您拥有什么样的建筑结构。

Web MVC可以变得非常主观，因为它与应用程序具有状态的MVC模型完全不同。在处理Web应用程序时，我尝试将主要功能保留在 Controller 之外。我喜欢它们实例化一些对象或模型，根据所执行的操作运行一些方法，并收集一些View数据，以在完成后传递给View。越简单越好，我将核心业务逻辑放入了模型中，这些模型应该可以代表应用程序的状态。

希望能有所帮助。