1

我的想法：

由于各种原因，我绝对鄙视存储过程：成本、可伸缩性和兼容性。

  • 成本：我可以用一台好的 MySQL 服务器的成本获得 2-3 台好的轻量级 Web 应用程序服务器。

  • 可扩展性：当然我可以缓存查询结果，但是当使用存储过程时，我失去了获得更精细的缓存粒度的机会，而且它将应用程序与始终使用 MySQL 联系起来（谁有钱从MySQL到别的东西？）

  • 兼容性：在某些时候 list_foo_widgetsByUser() 存储过程可能不适合客户端 #123 的需求。修改 list_foo_widgetByUser() 的签名将是自杀……所以我必须编写一个新的 sproc cl123_list_foo_widgetByUser()，这样会导致疯狂或杀人的 DBA。

我的解决方案：

从应用程序的存储库中提取模型并将它们放入外部存储库。然后，每个应用程序都会有一个指向外部存储库的 models/Base 子目录。然后在前面放置一个简单的工厂方法，例如 GetModel("FooWidgets")，它将 baseFooWidget 类作为实例或应用程序特定的子实例返回。这将允许单个应用程序继承 FooWidget 的类或与 Liquabase 等工具结合使用，从而允许更大的可变性基础。

我脑后有个声音说这太容易了……我在这里错过了什么？

参考资料：我知道 PHP Kohana 框架在这些方面做了一些事情，以允许应用程序设计人员用附加功能包装 Kohana 的基本库，如果 PHP 可以做到，我看不出任何其他语言有问题。

4

1 回答 1

3

摆脱存储过程是一个绝妙的想法，您的三分准确无误。

另一方面，PHP 不容易允许结构化包装。我不是 PHP 上瘾者（更多的是 C#/Java 人），但解决这个问题的最佳方法是单独的数据库/域/访问/业务层。简而言之：

  1. 在底部：数据库。只是表格，关系，就是这样。
  2. 然后你需要映射：代表你的表的简单对象。通常每个表一个对象。
  3. 接下来，您需要处理这些对象的方法。大多数表都需要“get all”、“get by id”和“save”方法。理想情况下，这些都进入一个单独的模块，因此可以在不需要更改映射的情况下进行开发。
  4. 最后，您需要您的业务逻辑，它可以进入一个单独的层或在您的应用程序中。

这是一个简化的概述。我不知道你的解决方案是不是这个意思，但这通常是它的方式：关注点分离。如果你改变数据库，你只需要改变映射。如果您需要不同的结果集，您只需更改访问层。

可以帮助您完成此过程的工具是 Hibernate（但您需要 JavaBridge），它是首选的ORM 工具，但学习曲线有点陡峭。对于 PHP，Doctrine 似乎可以为您做很多事情。其他工具也存在。理想情况下，工具允许双向工程：如果您更改某些内容，则再次运行该工具（或更改某些内容）并且您不会破坏应用程序。

于 2009-10-17T17:54:50.920 回答