Php 为什么要抽象我的数据层？

OOP原则对我来说很难掌握，因为出于某种原因，我无法将它们应用到web开发中。随着我开发越来越多的项目，我开始理解代码的某些部分如何使用某些设计模式，使它们更易于阅读、重用和维护，因此我开始越来越多地使用它

有一件事我仍然不能完全理解，那就是为什么我应该抽象我的数据层。基本上，如果我需要将数据库中存储的项目列表打印到浏览器中，我会执行以下操作：

$sql = 'SELECT * FROM table WHERE type = "type1"';'
$result = mysql_query($sql);

while($row = mysql_fetch_assoc($result))
{
    echo '<li>'.$row['name'].'</li>';
}

$sql='SELECT*FROM table WHERE type=“type1”；'
$result=mysql\u查询（$sql）；
while（$row=mysql\u fetch\u assoc（$result））
{
回显“
”.$row[“name]”。
；
}

我正在读这些关于PDO伟大之处的指南或文章，但我不明白为什么。我似乎没有保存任何LOC，也看不出它如何更易于重用，因为我上面调用的所有函数似乎都封装在一个类中，但做的事情完全相同。我看到PDO的唯一优势是准备好的声明

我并不是说数据抽象是一件坏事，我问这些问题是因为我正试图正确设计我当前的类，它们需要连接到数据库，所以我想我应该用正确的方法来做。也许我只是在读关于这个主题的不好的文章：）

---

我真的很感激任何建议，链接，或具体的现实生活中的例子的主题

考虑将数据层抽象为将来节省时间的一种方法

用你的例子。假设您更改了表的名称。您必须使用该表访问SQL所在的每个文件并对其进行编辑。在最好的情况下，这是一个搜索和替换N个文件的问题。如果只需编辑一个文件，即包含所有sql方法的文件，则可以节省大量时间并最小化错误

这同样适用于列名

这只是考虑到你重命名东西的情况。完全改变数据库系统也是完全可能的。例如，您的SQL可能在Sqlite和MySQL之间不兼容。你必须再次去编辑大量的文件

抽象允许您将一个部分与另一个部分解耦。在这种情况下，可以在不影响视图零件的情况下对数据库零件进行更改

---

对于非常小的项目，这可能比它的价值更麻烦。即使这样，你仍然应该这样做，至少是为了适应它。

我不是一个php的人，但这是一个更一般的问题，所以这里是

您可能正在构建一些小的东西，有时即使是中小型的东西也应该有一个抽象的数据层，这样它才能更好地发展

关键是要应对变化

想想看，你有一个小型社交网站。想想你将要存储的数据、个人资料详细信息、图片、朋友、消息。对于其中的每一个，都有类似于

pictures.php？&uid=xxx

的页面

然后，您将使用mysql代码在其中添加一小段SQL。现在想想改变这一点有多容易/难？你会换5-10页吗？当你这样做的时候，在你彻底测试它之前，你可能会出错几次

现在，想想Facebook。想想将会有多少页面，你认为在每个页面中更改一行SQL会更容易吗

正确抽象数据访问时：

它在一个地方，更容易改变

因此它更容易测试

它更容易更换。（想想如果你必须切换到另一个数据库，你必须做什么）

---

希望这有帮助

抽象数据层的另一个优点是不太依赖底层数据库

对于您的方法，如果您想使用mysql以外的其他东西，或者您的列命名更改或有关mysql更改的PHPAPI，那么您将不得不重写大量代码

如果所有数据库访问部分都被整齐地抽象出来，那么所需的更改将是最小的，并且仅限于几个文件，而不是整个项目

如果代码集中在一个地方，那么重用有关sql注入或其他实用功能的代码也会容易得多

最后，如果一切都通过某些类进行，那么进行单元测试比在项目的每个页面上进行单元测试更容易

---

例如，在我最近的一个项目中（很抱歉，没有代码共享），mysql相关的函数只在一个类中调用。从查询生成到对象实例化的一切都在这里完成。因此，对于我来说，切换到另一个数据库或在其他地方重用这个类是非常重要的。

在我看来，数据访问是从代码的其余部分分离/抽象出来的最重要的方面之一

分离不同的“层”有几个优点

1） 它整齐地组织您的代码库。如果必须进行更改，您将立即知道需要在何处进行更改以及在何处查找代码。如果你自己在做一个项目，这可能没什么大不了的，但是有了一个更大的团队，好处会很快变得显而易见。这一点实际上很琐碎，但我还是添加了它。真正的原因是第二

2） 你应该试着把可能需要独立改变的事情分开。在您的特定示例中，您可能希望在不影响用户界面的情况下更改DB/数据访问逻辑。或者，您可能希望在不影响数据访问的情况下更改用户界面。我相信你可以看到，如果代码相互混合，这是如何变得不可能的

当您的数据访问层有一个严格定义的接口时，您可以随心所欲地更改其内部工作，只要它仍然遵循该接口，您就可以非常确定它不会破坏任何功能

// Home page
$articles = $db->getTable('Article')->join('Author a')
    ->addSelect('a.name AS author_name');
$first_article_tags = $articles[0]->getRelated('Tag');

// Author profile
$articles = $db->getTable('Article')->join('Author a')
    ->addSelect('a.name AS author_name')->where('a.id = ?', $_GET['id']);

// Tag search results
$articles = $db->getTable('Article')->join('Author a')
    ->addSelect('a.name AS author_name')
    ->join('Tag')->where('Tag.slug = ?', $_GET['slug']);

// Home page
$articles = Author::getArticles();
$first_article_tags = $articles[0]->getRelated('Tag');

// Author profile
$articles = Author::getArticles()->where('a.id = ?', $_GET['id']);

// Tag search results
$articles = Author::getArticles()
    ->join('Tag')->where('Tag.slug = ?', $_GET['slug']);