问题标签 [front-controller]

我有一个用于许多不同操作的 servlet，用于Front Controller 模式。有谁知道是否可以判断发回给它的数据是否是 enctype="multipart/form-data"？在我决定之前我无法读取请求参数，因此我无法将请求分派给正确的控制器。

有任何想法吗？

在 PHP中实现 URL 解释器/调度程序（例如在Django和 RoR 中找到）的最佳方法是什么？

它应该能够按如下方式解释查询字符串：

• /users/show/4映射到
  • 面积=用户
  • 行动=展示
  • 编号= 4
• /contents/list/20/10映射到
  • 面积=内容
  • 行动=清单
  • 开始= 20
  • 计数= 10
• /toggle/projects/10/active映射到
  • 动作=切换
  • 面积 =项目
  • 编号= 10
  • 字段=活跃

其中查询字符串可以是指定的 GET / POST 变量，也可以是传递给解释器的字符串。

编辑：我更喜欢不使用 mod_rewrite 的实现。

编辑：这个问题不是关于干净的 url，而是关于解释一个 URL。Drupal 使用 mod_rewrite 将诸如http://host/node/5之类的请求重定向到http://host/?q=node/5。然后它解释 $_REQUEST['q'] 的值。我对口译部分很感兴趣。

我目前正在一个自定义框架中工作，该框架使用数据库设置一个页面对象，其中包含有关模块、视图、控制器等的信息，前端控制器使用这些信息来处理 MVC（显然）模式中的路由等。

处理数据库中页面的最初原因是因为我们需要能够在管理界面中动态创建新的登录页面，并且因为我们还需要创建可以附加其他动态对象的 onLoad 和 onUnload 事件。

然而，昨天读完这篇文章后，我想知道我们是否应该把这个处理移出数据库，让它像其他框架一样全是文件结构和代码驱动，这样就可以在没有数据库成为组件的情况下测试页面。

我目前正在考虑是否废弃自定义框架并使用标准框架之一并扩展它（这是现在最有可能的），但我想知道是否扩展框架以像我们一样通过数据库处理页面请求现在还是我们应该简单地使用框架附带的任何路由/处理机制？

我最近阅读了这篇文章，这导致了一系列其他文章似乎都暗示了相同的想法：模型做所有事情，视图应该能够直接与模型通信，反之亦然，而控制器则不受影响。然而，所有显示的示例都相当简单，没有一个真正显示任何人如何尝试实现对请求/响应周期的完整处理的示例，这让我想知道“模型是否应该负责处理请求（即$_GET、$_POST 等）本身？” 和“控制器是否应该仅作为传递来实例化必要的模型并将模型传递给视图？”。（事实上​​我发现了一个极端的例子，就是在模型中嵌入一个 Zend_Form 对象）

根据我对 Fowler 对 MVC 和控制器的一般看法的阅读，乍一看似乎控制器层越薄越好。但是后来我花时间回顾并研究了他对 MVC 和 Front Controller 的说法（这只是把水弄得一团糟，因为这两种模式都定义了控制器），现在我的直觉表明 Zend_Framework 在实现这两种模式时，实际上已经创建了一个复合对象，它执行 MVC 中的 Controller 和 Front Controller（或某些类似）中的 Command 对象的功能。

所以我想知道在他们的应用程序中实现了类似模式的其他人的一般意见是什么——你是完全在控制器层内处理请求，还是让模型知道请求并直接在模型内处理参数？

我目前为我的所有网站设计每个页面都有一个文件，然后包含常见的元素，如页眉、页脚等。但是，我注意到许多框架和 CMS 都使用前端控制器模式。

使用前置控制器有哪些优点和缺点？该模式是否只是在框架和 CMS 中使用，因为不知道最终系统中将存在哪些页面？

上下文：我打算使用 mod_rewrite （首页加载子页面）构建应用程序，但在从前端控制器页面加载 session_enabled 页面时卡住了。

问题：问题是我使用 session_start() 调用 twise，PHP 页面停止响应。奇怪的是， session_start 函数是无害的，它们在不同的页面上被调用。

我已将问题缩小到此示例：

child.php 文件：

父.php 文件：

调用 parent.php 将使浏览器无限加载。只要您评论其中一个 session_start() 调用 - 它会立即加载。

问题的根源是什么？我非常需要启用会话的页面。

PS我可以通过包含页面来解决它，但是它们依赖于 URL 参数，我想避免为了某种参数代理而修复它们。

视图管理和选择通常如何在桌面应用程序中完成？我知道 FrontController 是 Web 应用程序中的一种流行模式，但我觉得它不太适合桌面应用程序，因为选择页面比选择嵌套子视图更容易。

我的主应用程序视图是否需要了解所有子视图并根据应用程序事件决定要显示哪些视图？我会为子组件实现子 MVC/MVP 吗？

在 Spring MVC 中，Dispatcher servlet 用作“前端控制器”来处理所有应用程序请求并适当地路由它们。

是否可以在 Rails 中使用这种方法，或者是否需要为每种类型的操作编写单独的控制器，而无需“交通警察”（前端控制器）指导流程？

我正处于自己创建中小型 Web 应用程序的早期阶段。我阅读了“PHP 对象、模式和实践”并决定使用页面控制器，因为快速生产是一个高优先级。页面控制器也很有吸引力，因为我不熟悉 PHP 框架，并且创建一个精心制作的前端控制器目前似乎超过了该项目。我的计划是尽快发布网站的页面控制器版本，看看观众是否喜欢它，然后再进行更复杂的软件设计。

也就是说，我可能会决定在未来添加更多“模块”和开发人员......此时我真的应该切换到前端控制器。上面提到的这本书描述了“从页面控制器开始，向前端控制器模式移动并非不可能”，但“并非不可能”的措辞让我担心它可能会相当困难。

我的问题是：从页面控制器过渡到前端控制器设计有多“难”？在我的基于页面控制器的应用程序上工作时，我应该注意什么来创建允许平滑过渡到前端控制器设计的代码？理想的情况是尽可能少地重写/重构代码，并在前端控制器上添加相关的类/对象。现在我只对维护 MVC 持谨慎态度，所以经验丰富的开发人员的任何建议都会很棒。谢谢你。

我目前正在设置我的网站，主要是使用 php。虽然这是我第一次使用它，但我遇到了一些问题。

我已经掌握了网站的基础知识。注册、登录、个人资料页面等 然而这似乎是我必须对网站布局做出决定的地方。

例如。当前，用户的个人资料页面的 URL 为

mysite.com/profile.php

理想情况下，我希望它是类似的东西

mysite.com/user/ChrisSalij

通过阅读这篇文章，我相信我需要一个前端控制器风格的网站，尽管我不确定这一点，也不确定从哪里开始实施。

请记住，我对 php 之类的东西还很陌生，如果有任何有用的评论、链接和建设性的批评，我将不胜感激。

我非常愿意学习，因此文章和解释的链接会非常好。我通常会对这样的事情进行大量研究。但我对它太陌生了，我不知道从哪里开始。

编辑：我还应该补充一点，我计划将这个网站扩大到大规模。一开始它很小，但如果我的目标成功的话，应该会有很多页。所以我愿意现在就努力让它长期正确设置。谢谢