galvao/data-abstract

数据及其后续容器的抽象和泛化，旨在提供一个可以以相同方式处理所有形式数据的泛化。

维护者

详细信息

github.com/galvao/data-abstract

主页

源代码

问题

安装: 13

依赖: 0

建议者: 0

安全: 0

星标: 0

关注者: 2

分支: 0

开放问题: 0

dev-master 2015-06-17 13:16 UTC

Requires

  • php: >=5.4.0

MIT b323306b29acc81ae3e317d1e38e3a08a94ae74b

databaseabstractiondatageneralization

This package is auto-updated.

Last update: 2024-08-29 03:47:23 UTC

README

免责声明

这绝对是一个正在进行中的工作。它处于alpha阶段，还有很多缺失（见下面的待办事项）。这基本上意味着文件夹、文件甚至整个设计都可能在一夜之间发生变化：这里没有什么是固定不变的，任何东西都可能改变。

简介

这个想法最初出现在我作为一个面向对象和抽象的自我提出的练习中："能否将数据这样的概念抽象化成代码表示？如果可以，怎么做？？？也许更重要的是：这可以带来什么？"。后来我意识到，这对我在开发的另外两个个人项目至关重要，因为这两个项目都需要这种类型的抽象。为了保持DRY，我最终决定将其作为一个独立的项目。

目标是为数据和它的容器提供一个纯PHP、纯面向对象、递归的抽象。此外，还希望达到这样的抽象水平，使得无论数据来源如何，都可以以相同的方式处理数据。例如，以相同的方式处理JSON文件和关系型数据库实体。

结构

结构如下：数据 < 列 < 记录 < 实体 < 数据库 < 服务器 < 驱动。

尽管这里使用了一些非常具体的命名（例如，“数据库”），但这里每个概念都是泛化的：例如，“数据库”可能是一个磁盘目录。“实体”可能是一个JSON文档，等等。

每个容器都可以包含一个前一个对象，但这始终是可选的，以便可以以任何方向构建（从数据 -> 驱动或从驱动 -> 数据）。当然，你可以在任何步骤停止。

这个项目意味着什么以及它不是什么

这个项目意味着是

  • 面向对象和抽象的练习；
  • 用于多个项目的抽象层，因此可以避免编写WET代码；
  • “代码展示”，这样人们可以看到我是如何思考和编写的；

这个项目不是

  • “一件艺术品”；
  • 完美的；
  • “一刀切”的解决方案；
  • ORM；
  • 现有ORM的替代品；
  • 任何其他现有替代品的替代品；
  • 比现有ORM更好；
  • 比任何其他现有替代品更好；
  • 比现有ORM更差；
  • 比任何其他现有替代品更差。

待办事项

  • 适当的代码文档
  • 完成简单的具体实现示例
    • 数据
    • 列
    • 记录
    • 实体
    • 数据库
    • 服务器
    • 驱动
  • 测试和重构
    • 单元测试
    • 负载测试（性能）

人们可能会说的话以及我如何回应

  1. 项目X正好做你试图做的事情，而且做得很好！ 很酷，很好，我会在完成这个之后确保看看。如前所述，这也为我提供了一个研究。

  2. 将任何数据结构化为数据库实体这一想法是愚蠢的，注定会失败。 是吗，真的吗？你100%确定吗？我不确定，所以我将尝试，如果失败了……好吧，那就失败了。=) 我要告诉你：如果失败了，我会在这里记录失败的原因，并保留其最终状态作为研究资料。

  3. 为什么不使用组件X、Y或Z呢？ 首先，目标不是制作另一个ORM，甚至与任何现有的类似项目竞争（参见上文）——连这样做都不可能，因为这里的主要目标是抽象化；具体实现是次要的，可能或可能不会作为示例出现在这个仓库上。其次，ORM或其他组件通常有自己的做事方式，我可能不同意它，或者目前对项目X、Y或Z不感兴趣，有n个原因。

  4. 它完成了吗？ 没有，还远未完成（参见上文的免责声明和待办事项），实际上。它甚至还没有达到我想要的成熟度。我基本上只写这些是为了两个原因

  5. 让人们理解这究竟是什么，以及我是如何设计它的。

  6. 还有 嘎嘎！

  7. 我认为你在“这里”，“这里”或“这里”是错的。 很好，打开一个问题，让我们讨论一下。