用于构建相对复杂的PHP Web服务的设计模式

Question

用于构建相对复杂的PHP Web服务的设计模式

phpweb-servicesapidesign-patternsframeworks

21

我刚刚完成了一个比较复杂的PHP Web服务的编码。由于最后一刻的请求、更改和添加等常规操作，代码库现在有些混乱。

我试图尽可能轻量级地编写代码，并以最大化性能的方式进行编码。

因此，我没有使用任何框架（如Zend）或ORM（如Doctrine）。

我想知道是否有任何框架或设计模式专门用于构建PHP的API / Web服务？

我正在考虑重构，并希望确保现在我清楚地知道其中涉及的内容，可以正确地构建这个东西。

- Evernoob

好问题，我认为一个真正优秀的轻量级框架的标志应该是它同样适用于API和Web服务以及Web前端。 - Nicole

看看 FRAPI - http://getfrapi.com/ 它是由 echolibre 公司开发的，该公司包括一些 PEAR 领导人员。 - CaseySoftware

4个回答

0

我认为您可以使用与简单Web应用程序相同的模式。RESTful服务具有不同于Web应用程序的接口，但接口下的所有内容都是相同的。您可以按如下方式将RESTful服务转换为Web应用程序：

METHOD host/resource/data => host/resource/METHOD?data

资源是控制器，方法是动作。例如：

GET http://library.com/books/123 => http://library.com/books/get?123

因此，您可以使用前端控制器和MVC。

- inf3rno

像“deactivate”或“children”这样的操作/方法怎么样？ - Rudie

0

在我看来，每个基于MVC的“东西”都可以真正帮助你。

如果你真的不想使用任何已经存在的东西（试试CakePHP!），那么按照MVC结构化你的代码可以帮助你将应用程序的逻辑分割成更多层，并使其更易读和调试。

当然，即使有更好的模式，你也可以编写糟糕的代码，这取决于你！

- Enrico Carlesso

1

由于我正在编写一个API，MVC设计模式并不适用，因为控制器没有真正的“操作”，也没有“视图”。 - Evernoob

我在回答时就在考虑这个问题，但它严格取决于你如何编写API...如果API以某种方式符合RESTFul标准，那么MVC模式是适用的...这就是我的答案之所在，但我看到它并不适用于所有情况！ - Enrico Carlesso

6

在这种情况下，“view”是指你发送回客户端的任何内容。“action”是指你的服务被请求执行的操作。 - Mchl

1

@Evernoob：REST API 几乎完美地符合 MVC 模式。而且，CakePHP 很慢。 - coreyward

-1

我快速谷歌了一下，发现以下内容：

我从未使用过这些东西。

- Phill Pafford

8

每个人都可以使用谷歌。你想表达什么？ - sanmai

3

根据我的学校经验，那完全不是真的。 - Shawn Mclean

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Nicole · Accepted Answer

我提前为自己的框架做了一些自我介绍，这是因为如果不用它的话，我无法帮助你。我没有广告，因为它是不公开的。

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

由于我对任何流行的PHP框架（CodeIgniter、CakePHP、Kohana）都感到不满，因为它们处理请求的方式太过受限，并且它们的大小也很大，所以我编写了一个仅针对两个目的而设计的框架：处理请求并确定要采取的操作，然后将该操作的代码与视图（响应）分离。

我使用的设计模式如下：

所有URL都被重写(mod_rewrite)，并传递给您执行的入口点。
您的入口点设置路径，以便它能够识别和处理。例如，对于Web服务：
- /users - 用户列表
- /user/* - 根据*的值确定的用户。
- /user/*/delete - 删除用户
- /posts - 帖子列表
- /post/* - 查看帖子*
除了路径之外，您还要指定一个函数，例如UserActions::saveUser在HTTP方法是POST时执行。之所以只在POST上执行，是为了使输出和输入具有相同的URL。
该路径还指定了一个视图。这是将发送到浏览器的响应正文。它可以直接呈现为PHP，或者您可以插入一个模板引擎。在Web服务的情况下，所有路径可能会使用单个视图，以在输出格式（JSON、XML、任何其他）中呈现数据。视图可以仅作为PHP方法，并且不需要指定模板文件。

在Web前端的情况下，视图可以有一个包装它的父视图（从内部向外创建页面）。

最后一点是安全性。您可以定义应用于任何路径的安全类型。安全类型仅指定要检查授权的函数（如SecurityManager :: authorize），如果返回false，则将重定向到您选择的路径。

我认为这种设计模式适用于Web服务的原因：

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