我正在开发一个 Web 应用程序,它将广泛使用 AJAX 技术进行客户端/服务器通信......特别是 JSON-RPC。Zend Framework 正在服务器端使用,它提供了一个不错的 JSON-RPC 服务器,我想使用它。
我的目标是构建一个可维护的系统,将服务器端功能的大部分子集暴露给客户端(javascript),而不需要不必要的代码重复。我看过许多关于如何使用 ZF 的 JSON-RPC 服务器的博客文章和教程(请参阅此处和此处),但它们似乎都旨在公开一个小型的、可公开使用的 API。代码重复很常见,例如一篇博客文章公开了以下方法:
public static function setTitle($bookId, $title) {
$book = new Nickel_Model_Book($bookId);
$book->setTitle($title);
$book->update();
return true;
}
我不喜欢有两种setTitle
方法的事实。如果一个方法签名发生变化,另一个必须保持同步......如果您的 API 很广泛,这似乎是可维护性的噩梦。在我看来,应该有一个Book
类,一个setTitle
方法。
@export
我最初的想法是为我想要公开的方法/类添加一个 docblock 注释。当我决定公开该setTitle
方法时,我只是添加注释而不是新方法。
我看到的一个潜在问题涉及对象持久性。在服务器端,设置对象的 title 属性是有意义setTitle
的……但在调用之前不要将其保存在数据库update()
中。在客户端,调用setTitle
应该立即影响数据库。一种可能的解决方案是修改所有访问器,以便它们采用可选的第二个参数,表示修改应立即更新数据库:
function setTitle($title, $persist = false) {
$this->title = $title;
if ($persist) $this->update();
}
某种代理类可以确保$persist
为所有客户端 RPC 调用设置标志。
另一个问题是 PHP 对象的序列化。在服务器端,进行 OO 风格的$book->setTitle("foo")
调用是有意义的,但由于缺少状态,客户端book.setTitle(1234, "foo")
是有意义的(其中 1234 是书的 ID)。我对此的解决方案是让上述代理类负责以某种方式book.setTitle(1234, "foo")
变成:
$book = new Book();
$book->load(1234);
return $book->setTitle($title);
我觉得这个问题之前一定已经解决或讨论过......但我没有在网上找到很多资源。这看起来像一个理智的解决方案吗?