关于 PHP 资源类封装的问题

[lml12377]

这两天在看 java URL/URI 和 spring Resource，产生一个想法，能不能把 php 中 PDO/file/cache 统一起来？

很多 php 框架在对文件操作方面设计了 FileSystem component，cache 大多也是独立的模块（ psr6/16 ）。

pdo 全称是 php data object，原则上来讲 file/cache 也应该属于 data source，另外 dsn = data source name，这个 dsn 其实格式上跟 uri 很像（ dsn URI invocation 其实还是为了找到 dsn 字符串），为什么 PDO 不把 file/cache 操作也封装进来呢？为它们设计一套 dsn。

或者当我个人在设计 Resource 的时候，是不是可以设计一层 wrapper，把 PDO/FileSystem/Cache 封装起来，在 PDO dsn 之上加入新的 dsn 规则，通过 ResourceFactory 配合 DsnParser 来创建出不同的 Resource 实例？

Resource 接口除了基本的 getInputStream/read 这种读取字节流或者字符串的方法之外，还提供 getFile/getCache 来适应 FileResource/CacheResource 的情况。

比如：

cache:adapter=redis;host=127.0.0.1;port=6379

便返回一个可以操作 redis 的 Cache 实例（继承自 Resource 接口）

file:url=/foo/bar/test.txt

返回一个 FileSystem 实例（"file:" 其实属于 URL 的 protocol，可以考虑把 dsn 统一映射到一套自定义的 URI 规则上）

不知道这套方案是否可行，或者已经有人这么做了？

[minbaby]

The PHP Data Objects (PDO) extension defines a lightweight, consistent interface for accessing databases in PHP.

我把原文 copy 过来了, ` for accessing databases` 这个是 PDO 的目标，也就是说，如果你可以把文件系统抽象成 database 的话，理论上是没有问题的。

对于缓存来说，它本来就是一种抽象了，具体实现可能有 DB, File 等等。

在回头看楼主的假设， 文件系统 、PDO、CACHE，这三者如果可以抽象出公共部分，那么自然可以统一成一套流程， 如果无法抽象公共部分，那就可以放弃了。

ps: 楼主可以试着写写（我只负责围观）。

[lml12377]

@minbaby 写完回头看了下，发现其实 PDO 和 Resource 之间好像并没有公用的部分，Resource 加上 getPDO() 好像又没什么意义。。。

[minbaby]

@lml12377 哈哈，我就喜欢脑洞大的人，很好玩