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

Question

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

2) 如果您需要针对多种类型用户的仪表板，那是一个仪表板控制器，它具有取决于哪个用户的切换代码，还是您会在每个用户的每个控制器中说一个仪表板操作？例如admin/dashboard、account/dashboard等

3) 在我看来，在尝试解释控制器时，使用整个简单的 CRUD 示例就像一个魅力，但是一旦你超越了这些简单的功能，它就会崩溃并且可能导致你的控制器变得笨拙。为什么有些人选择创建登录控制器，而其他人在用户控制器中制作登录功能？我认为的一个原因是，我们很多人都来自页面方法背景，很难将控制器视为“对象”或“名词”，因为页面并不总是以这种方式工作。举个例子，你到底为什么要创建一个“页面”控制器来处理实际上彼此无关的页面，只是为了有一个“容器”来适应动作。只是我觉得不合适。

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

控制器可能不应该这么混乱，但出于某种原因，它们让我大吃一惊。任何有用的 cmets 将不胜感激。

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 的 URL 将运行 actionAbout()，这将加载 About 页面模板。由于 about 页面是完全静态的内容，我的 actionAbout() 绝对没有做任何事情，除了提供一个公共操作供前端控制器查看和运行。

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

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

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

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

我建议将一些 PHP ORM 框架用于 CRUD。他们可以省去很多获得良好实现的麻烦。

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

4) 你说得对。您可以轻松创建一个控制器来处理您的应用程序/网站想要做的所有事情。但是，我认为您会同意这将成为维护的噩梦。回想起我在一家市场研究公司的上一份工作时，我仍然会有些笨拙，那里的内部 PHP 应用程序是由一个海外团队完成的，我只能假设几乎没有培训。我们说的是处理整个站点的 10,000 行脚本。无法维护。

因此，我建议您将您的应用程序/网站分解为业务领域，并在此基础上创建控制器。找出应用的核心概念，然后从那里开始。

示例

假设我有一个关于海牛的网站，因为显然海牛很摇滚。我想要一些普通的网站页面（关于、联系方式等）、用户帐户管理、论坛、图片库，也许还有一个研究文档资料区（关于海牛的最新科学）。很简单，而且很多都是静态的，但是您可以开始看到故障。

IndexController - 处理页面、隐私政策、通用静态内容。

UserController - 处理帐户创建、登录/注销、首选项

PictureController - 显示图片，处理上传

ForumController - 可能不多，我会尝试集成一个外部论坛，这意味着我在这里不需要太多功能。

LibraryController - 显示近期新闻和研究列表

HugAManateeController - 通过 HTTP 实时拥抱的虚拟海牛

这可能至少给你一个基本的分离。如果您发现控制器变得非常大，则可能是时候将业务域分解为单独的控制器了。

每个项目都会有所不同，所以稍微规划一下对于您将拥有什么样的建筑结构大有帮助。

Web MVC 可能会变得非常主观，因为它与应用程序具有状态的 MVC 模型完全不同。在处理 Web 应用程序时，我尝试将主要功能排除在控制器之外。我喜欢他们实例化一些对象或模型，根据所采取的操作运行几个方法，并收集一些视图数据，以便在完成后传递给视图。越简单越好，我把核心业务逻辑放到模型中，模型应该代表应用的状态。

希望对您有所帮助。