使用 PHP 的多层应用程序？答案

【问题标题】：Multi-tier applications with PHP?使用 PHP 的多层应用程序？
【发布时间】：2009-09-06 12:57:14
【问题描述】：

我对 PHP 比较陌生，但在具有 SOA 架构和多层应用程序的复杂企业环境中经验丰富的 Java 程序员。在那里，我们通常会在中间层实现具有业务逻辑的业务应用程序。

我正在编写一个替代货币系统，该系统应该易于部署和由个人和社区定制；它将是开源的。这就是为什么 php/mysql 似乎是我的最佳选择。

用户有帐户，他们会得到余额。此外，系统会根据提供的总服务和总可用资产计算价格。

这意味着，在购买时会发生一系列计算；余额和总数得到更新；这些是派生的数字，通常不会放入数据库中。

尽管如此，我还是将触发器和存储过程放入了数据库，因此在 php 代码中没有进行这些更新。

人们怎么看？这是一个好方法吗？我的经验告诉我，这不是最好的解决方案，并促使我实施中间层。但是，我什至不知道该怎么做。另一方面，我目前所拥有的 store procs 在我看来是最合适的。

我希望我的问题说清楚了。所有 cmets 赞赏。可能没有“完美”的解决方案。

【问题讨论】：

标签： php mysql database stored-procedures multi-tier

【解决方案1】：

就像现在的趋势一样，远离数据库通常是一件好事。您可以更轻松地进行版本控制，并且只需使用一种语言即可工作。不仅如此，我觉得存储过程是一条很难走的路。另一方面，如果你喜欢这些东西并且对 MySql 中的 SP 感到满意，它们还不错，但我的感觉一直是它们更难调试且更难处理。

关于触发器问题，我不确定您的应用是否需要这样做。由于触发计算的事件是由用户调用的，因此这些事情可能在 PHP 中发生，即使用户同时被重定向到“等待”页面或另一个页面。显然，真正的触发器只能在数据库级别完成，但您可以使用每 X 秒运行一次 PHP 脚本的守护线程......不惜一切代价避免这种情况，并尝试让事件从用户端触发。

说了这么多，我想在 PHP 上插入我最喜欢的数据访问层解决方案：Doctrine。它并不完美，但 PHP 就是这样，它已经足够好了。完成您想要的大部分工作，并让您使用对象而不是数据库过程等。

关于你的标题，多层在 PHP 中是完全可行的，但你必须这样做并尊重它们。 PHP 代码可以调用其他 PHP 代码，现在（5.2+）很好地面向对象等等。请务必忽略这样一个事实，即您将看到的许多 PHP 代码完全是垃圾，甚至不使用方法，更不用说层和体面的 OO 建模了。如果您愿意，一切皆有可能，包括您自己（或使用现有的）MVC 解决方案。

【讨论】：

顺便说一句，使用存储过程并不一定排除拥有源代码控制，相反，您可以而且应该将所有代码放入源代码控制中。
真反，任何东西都可以进行版本控制，但 PHP 代码特别适合。 MySql SP 卡在 DB 中，对吧？
不，您将 SP 源代码保存在文件中（因此保存在版本控制中），然后在部署时将它们加载到数据库中。容易:)

【解决方案2】：

将大量功能推送到数据库级别而不是数据抽象层的一个问题是，您会被锁定在 DBMS 的功能集中。开源软件通常被编写为可以与不同的数据库一起使用（当然并非总是如此）。将来您可能希望轻松移植到 postgres 或其他一些 DBMS。现在使用大量 MySQL 特定的特性会使这变得更加困难。

【讨论】：

【解决方案3】：

使用数据库服务器提供的触发器和存储过程以及其他功能绝对没有错。它运行良好，运行良好，您正在利用数据库的全部潜力，而不是简单地将其归为简单的数据存储。

但是，我敢肯定，对于这里所有同意你（和我）的开发者来说，至少有同样多的人认为完全相反，并且在这方面有很好的经验。

【讨论】：

【解决方案4】：

谢谢大家。

我使用数据库触发器是因为我认为这样控制事务完整性可能更容易。您可能已经意识到，我是一名开发人员，也在努力掌握数据库知识。

现在，我看到了将 php 代码分布在多个层上的解决方案，不仅在逻辑上，而且在物理上也可以通过部署在不同的服务器上。

但是，在这个开发阶段，我想我会坚持我的触发器/sp 解决方案，因为这并没有那么错。在多个层上分布需要我不断地重新设计我的应用程序。

另外，考虑到开源，如果有人喜欢替代货币系统，人们可能更容易根据他们的要求更改布局，而我不必担心如果人们接触 php 代码会导致计算错误。

另一方面，我当然同意 db 的东西可能很难调试。

DB 初始化脚本和 php 文件一样在源代码控制中：)

再次感谢

【讨论】：