构建相当复杂的 PHP Web 服务的设计模式 [已关闭]

我提前为我自己的框架的自我引用道歉 - 否则我没有办法帮助你，因为我不使用其他任何东西。我不是在做广告，因为它不是公开的。

正如我在评论中所说，我认为一个好的Web前端框架不应该意味着它是一个糟糕的Web服务框架。

因为我对任何流行的PHP框架（CodeIgniter，CakePHP，Kohana）处理请求的限制性方式以及它们的大小不满意，所以我写了一个框架，它实际上只设计用于两个目的，处理请求并确定要执行的操作，然后将该操作的代码与视图（响应）分开。

我使用的设计模式是这样的：

1. 所有 URL 都将被重写（mod_rewrite）并传递到执行入口点。
2. 入口点设置它将识别和处理的路径。即对于 Web 服务：
   • /users- 用户列表
   • /user/*- 由值标识的用户。*
   • /user/*/delete- 删除用户
   • /posts- 列出帖子
   • /post/*- 查看帖子*
3. 除了指定函数的路径外，还指定了一个函数，即 如果 HTTP 方法是 POST，则执行。它仅在 POST 上执行的原因是使输出和输入具有相同的 URL。UserActions::saveUser
4. 该路径还指定视图。这是将发送到浏览器的响应正文。它可以呈现为直接的PHP，或者你可以插入模板引擎。对于 Web 服务，所有路径都可能使用单个视图，该视图以输出格式（JSON、XML 等）呈现数据。视图可以只是一个 PHP 方法，不需要指定模板文件。
5. 对于 Web 前端，视图可以具有包装它的父视图（从内到外创建页面）。
6. 最后一点是安全性。您可以定义要应用于任何路径的安全类型。安全类型只是指定要检查授权的函数（如），如果返回，它将重定向到您选择的路径。SecurityManager::authorizefalse

我相信这种设计模式适用于 Web 服务的原因如下：

• 使您能够使用单个入口点，但可以与多个入口点一起使用（用于优化，如果需要）。
• 不要假设您希望您的URL与您的对象模型匹配，就像大多数主要框架一样（一个值得注意的例外是Zend，如注释中所述）。
• 很容易适应 REST（而不仅仅是检查 ，也检查其他方法）。POST
• 删除任何HTML感觉都是完全自然的，因为在这种模式中，响应与处理完全分开。
• 这都可以在几个课程中完成。

恕我直言，每个基于MVC的“东西”都可以真正帮助你。

如果你真的不想使用任何已经存在的东西（试试 CakePHP！），那么按照 mvc 编写你的代码可以真正帮助你在更多的层上拆分应用程序的逻辑，并使其更具可读性和可调试性。

当然，使用更好的模式，你可以写出糟糕的代码，这取决于你！